Add a co-maintainer in stages. Start with Triage, move to Write after a few reviewed contributions, and hold Admin and publishing rights back until you have worked together for a while. Each role adds specific powers, so pick the lowest one that lets the person do the work you need.
Know what each role can do
GitHub's repository role table is a good checklist. In short:
- Triage can label, close, reopen and assign issues and pull requests. It cannot push code or manage workflows or secrets.
- Write can push to unprotected branches, merge pull requests and approve reviews. It can also create and edit workflows, manage Actions secrets, publish packages and edit releases.
- Maintain adds repository housekeeping and the ability to push to protected branches, but not settings, webhooks, deploy keys or access management.
- Admin manages security settings, branch protection and rulesets, and can delete or archive the repository.
Notice that Write already includes workflows, secrets and releases. That surprises many maintainers. Handing out Write is handing out the keys to your build.
A staged path
- Triage first. Let them sort issues for a few weeks. You learn how they communicate, and the downside is small.
- Write with required review. Turn on branch protection so their merges still need an approval. See branch protection rules worth enabling.
- Maintain. Give it when they handle releases with you watching.
- Admin only when needed. Many projects never need a second admin. If you do, make sure that person uses strong two-factor authentication.
Check the person, not just the profile
You cannot verify everyone fully, and you should not pretend to. Useful signals include a history of constructive contributions, a consistent identity across the project, and willingness to work in public. The xz backdoor case showed how patient social pressure on an overworked maintainer can be. Take your time, and treat unusual urgency to grant access as a warning. The timeline is in xz utils backdoor and maintainer pressure.
Set expectations in writing
Before you grant rights, agree on:
- Two-factor authentication on their account, ideally with a hardware key. See maintainer 2FA methods ranked.
- Who may cut releases, and how.
- That workflow and release script changes always get a second review.
- How access ends, which is covered in the offboarding checklist.
Put it in a short MAINTAINERS or GOVERNANCE file so it is not a private understanding.
Registry access is separate
GitHub access is not the same as package registry access. Add publishing rights on npm, PyPI or similar as a distinct decision, and prefer publishing from CI so no individual needs a long-lived publish token.
Quick check
Can a Write user change my CI secrets?
Yes. The role table lists managing Actions secrets and variables under Write. Treat Write as sensitive.
Do I need a second admin?
Not always. A second admin helps if you could lose access, but it doubles the number of accounts that can change settings.
Sources
Last reviewed: 19 October 2026.
