Maintenance is accepted with the component, not after the merge

What it is

A merge is not a gift. It is taking on a liability that keeps accruing interest: theme revisions, platform upgrades, contrast claims, deprecation notices will knock on that name again. Ownership on merge requires that, at the same moment the code lands, a current person, rotation, or team says “bugs and follow-on changes come to us” — not a footer that says “issues welcome”, not silence after the merge party. Write-access says who may send it in. Maintenance says who is still there after it is in.

A component with no acceptor is an orphan. The next breaking change arrives to a calendar with nobody’s name on it.

Why it happens

Once code sits in the shared library, failure stops meaning “this page broke” and starts meaning “every calling page broke together”. Fixes need someone on a schedule. Contributors ship the piece under feature pressure, then return to the product line when the pressure lifts. If the system team did not nod at merge time, the piece sits in the band where anyone may edit and no one must. Platform point releases, token renames, assistive-tech updates keep their own calendars; they do not wait for the original author to be free. Acceptance books the liability to an account that still has headcount: an on-call roster, code ownership, a triage queue. “Merge passed” with no account books the liability to air.

Ownership can be handed on, but the handoff is itself an explicit event: old account closed, new account opened, no gap in between.

Where it stops holding

Vendor controls pulled in as a dependency live on the vendor’s support contract, not on this library’s roster; what this library must name is the owner of the wrapper, not every upstream line. Trial pieces marked to expire may have a short acceptance window and then be deleted — no need to pretend they have a long-term owner. Weekend personal projects and intern work that cannot name a successor after the internship should not merge into the public library. In a one-person company the acceptor is that person and process can shrink; the moment a second person starts calling, orphan risk appears and the account must be written down. An author leaving is a forced handoff: no new account before they go, remove or freeze the piece rather than defaulting to “someone on the team will see it”.

Applying it

• Last item on the merge checklist is the maintenance account: a person or rotation, plus the default assignee in the tracker. Missing that item, no merge.
• Keep CODEOWNERS in sync with that account; the reviewer of the component directory is the person who will be auto-pinged.
• Confirm quarterly that people on the account are still employed and still claiming the work. Exit processes include “transfer or delete components in their name”.
• Check: for each shared component, file a harmless test ticket (or inspect the last real defect’s response). An account that claims it inside the agreed window means acceptance is real. A ticket hanging, routed to a deactivated user, or attracting “who wrote this?” means merge-time ownership was ceremony. Sample components whose original author has left: if no successor account exists, they go onto a delete-or-rehome queue immediately.

Related

• Same group: R1.06.1 Who may add a component must be named · R1.06.2 An ungoverned system decays into a component pile · R1.06.3 High contribution cost drives teams around the system · R1.06.4 Promote only after several real call sites exist · R1.06.5 Review the public API, not the implementation internals
• Adjacent: R1.12 Usage guidelines and anti-examples · R1.18 Adoption and compliance metrics
• Search terms: ownership on merge · maintainer of record · component ownership