Protecting your time¶
- Automate everything you can: CI, formatting, releases, stale-issue labelling, dependency updates.
- Use templates to get complete bug reports the first time.
- Saying no is part of the job. "Thanks, but this doesn't fit the project's scope" is a complete, kind answer. Every feature you accept is a feature you maintain forever.
- Document decisions (a
docs/decisions/folder or a FAQ) so you don't re-argue them in every issue. - Set expectations publicly: "This is a side project; I review MRs on weekends."
Growing contributors into maintainers¶
- Respond to first-time contributors quickly and warmly — a first MR answered in a day turns into a second MR; one ignored for a month never does.
- Give commit access to people who've demonstrated sustained, good-quality contributions.
- Write down how the project is governed, even if it's one paragraph ("I make final decisions; regular contributors can earn merge rights").
Burnout and the xz lesson¶
The xz backdoor worked because a single, exhausted maintainer was under sustained social pressure to hand over control. Takeaways:
- Be wary of sudden pressure campaigns to "add a co-maintainer" or "speed up releases," especially from new accounts.
- Grant elevated access gradually, and verify contributors over time.
- Use protected branches, required reviews, and signed commits so no single account can unilaterally ship a release.
- It's acceptable to step back. Archive the repository, add a notice, or hand it to a foundation. A project marked unmaintained is safer than a project silently abandoned or handed to a stranger.
Retiring a project¶
If you're done:
- Update the README with a clear notice and any recommended alternatives.
- Archive the repository (read-only).
- If others want to continue it, either transfer it to a trusted person/organization or encourage a fork with a different name.