H.4 Ownership
A CODEOWNERS match can answer who must approve a path while saying nothing about who maintains it, understands its domain, repairs it in an incident, or decides to retire it. Ownership works when those roles and their failure modes are visible instead of compressed into one name.
Map Responsibility Before Routing Review
Start with a cross-team change to a shared component. H.4.1 Team Boundaries maps the domain, component, platform, enabling, or temporary teams and the interaction mode among them. The map explains where cognitive load and change flow are meant to stay local; it does not grant approval by itself.
H.4.2 Stewardship adds maintainers, experts, escalation, discoverability, and retirement responsibility. Then H.4.4 Review Authority identifies the peer, steward, domain, language or platform, and special-policy roles the candidate actually requires.1 One reviewer may satisfy several roles; requiring one reviewer from every consumer is a different and often much heavier policy.
Cross The Boundary Without Erasing It
H.4.3 Contributions lets an engineer propose and implement change outside their usual area while local stewards retain approval and long-term maintenance. It also names who updates consumers and completes deprecation, which may be the contributor, component steward, or a migration team.
H.4.5 Ownership Failure tests the map against orphaned code, overloaded authorities, repeated reassignment, and stale ownership records. An owner of last resort coordinates recovery; that role should not silently become the permanent maintainer for every abandoned domain.
Finally, H.4.6 External Contributions handles the harder boundary where forks, mirrors, exported subsets, upstream synchronization, contributor agreements, and untrusted validation connect an internal repository to outside contributors. Source access and CI trust still constrain that path; permission to propose a patch does not grant read access or approval authority.
Ownership is a map of maintenance, expertise, approval, contribution, and escalation roles across internal and external boundaries. Build the role map first, route only the authority a change needs, and treat orphaning or concentrated load as a responsibility failure—not as a reason to add more names to an already false record.
Footnotes
-
Software Engineering at Google — Ch. 9: Code Review — reviewer roles, ownership, and review authority at scale ↩
Sections in this chapter · 6
Compare domain, component, platform, enabling, federated, and temporary team boundaries through change flow and cognitive load.
Record maintenance, expertise, discoverability, and retirement responsibility without treating stewardship as possession.
Let people change code beyond their usual area without erasing local stewardship or consumer obligations.
Route a concrete change to the required peer, steward, domain, platform, or special-policy approver without redefining policy authority.
Detect and recover from orphaned code, false ownership records, overloaded authorities, and missing escalation.
Operate forks, mirrors, upstream synchronization, contributor agreements, review, and untrusted validation as one contribution path.
