Purpose
To define ownership rules for codebases, modules, and services so that accountability, quality, and maintainability are clear.
This prevents “orphaned code,” reduces knowledge silos, and ensures smooth collaboration across squads.
Scope
- Applies to all repositories, services, and shared libraries.
- Used by Developers, Tech Leads, and Architects.
- Covers module ownership, change approvals, and escalation paths.
Principles
- Clear Accountability – Every file/module must have an identified owner.
- Collective Responsibility – While ownership exists, teams collaborate on quality.
- Transparency – Ownership must be visible in repo metadata.
- Sustainability – Owners must document and share knowledge to avoid bottlenecks.
Rules & Standards
Ownership Rules
| Area | Policy Standard |
| Repository Ownership | Each repo has a primary squad and secondary reviewers. |
| Module Ownership | Each module/service has at least 1 Lead Owner and 1 Backup Owner. |
| Shared Libraries | Must have cross-squad maintainers assigned. |
| Orphan Code | Any unowned code must be reassigned within 1 sprint. |
Change Approval Rules
| Change Type | Required Approvals |
| Module-level change | Owner approval mandatory |
| Cross-service change | All affected owners approve |
| Critical (infra/security) change | Owner + Tech Lead + Security reviewer |
| Shared lib update | Owner + 1 external consumer squad |
Knowledge Transfer
- Owners must:
- Maintain module README.
- Document key flows (API, DB schema).
- Run walkthroughs for backup owners.
- When an owner exits, the transfer happens before the exit (handoff checklist).
Governance
- Audit: Quarterly audit of
CODEOWNERSand repo documentation. - Escalation: If no owner responds in 2 days → escalate to Tech Lead.
- Transfer: Ownership changes logged in ADR.
- Violations: PR merges without owner approval → flagged in review metrics.