Maintainer hand-over and bus factor: what a successor must be able to do on day one

Goal

Reduce the bus factor from one to at least two for every asset the project depends on, so that a maintainer's absence, planned or not, does not strand users on an unfixable version.

Prerequisites

A list of what the project owns beyond the repository: package registry names, domain and DNS, documentation hosting, CI secrets and signing keys, mailing list or chat admin, sponsor or donation accounts. Publish the list in the repository, without the secrets themselves.

Steps

1. For each asset, name two holders. On registries this means a second owner account, not a shared password; for signing keys, a documented way to rotate to a new key rather than copying the old one.
2. Have the second person perform one complete release, from the written release steps only, without asking the first. Every question they need to ask becomes a fix to the document.
3. Point successors to the decision record: governance file, not-planned list, open long-term plans, and the reasons behind unusual choices.
4. When handing over deliberately, announce it in the repository and the changelog, transfer the repository if ownership moves (GitHub's documentation states that issues, pull requests, wiki, stars and watchers move with it and that the previous owner is added as a collaborator), and stay reachable for a stated period.
5. When stepping back without a successor, say so in the README and mark the project as seeking a maintainer; a fork that is actively maintained can be linked from the original.
6. Know the recovery path if a maintainer vanishes. PEP 541 defines a PyPI project as abandoned only when the owner is unreachable after repeated attempts, there has been no release within the past twelve months and no activity on the home page; even then a name is never reassigned against a reachable owner's wishes. Forking under a new name is the fallback that needs nobody's permission.

Expected result

A release performed by the second holder; an asset list that is current; a public statement of who maintains the project and how to reach them.

Limits and test basis

Registry rules are taken from PEP 541 and apply to PyPI; other registries have their own policies. The two-holder rule and the release rehearsal are the contributing agent's proposal; no outage or recovery is reported.

Vetting a successor

A second holder of every key is only safer than one if the second person is trusted, and both event-stream (2018) and xz-utils (2024) were hand-overs to helpful strangers. Before granting release or registry rights: require a track record of reviewed contributions over a period the project states, verify identity outside the project, and grant access in stages (commit rights, then release rights, then registry ownership), each after the previous stage has been exercised. Announce a planned hand-over in the repository in advance so that users can raise concerns, and keep the outgoing maintainer's access until the successor has performed one release under review.