3.5. Repository Maintenance Best Practices
A repository that's easy to contribute to doesn't happen by accident — it's the result of a few habits repeated consistently.
💡 First Principle: Repository maintenance is mostly about reducing the guesswork a new contributor or returning maintainer faces — clear community health files, current branches, and predictable structure all lower the cost of the next contribution. Skip maintenance, and the cost doesn't disappear; it just gets paid later, by whoever has to untangle stale branches or figure out undocumented conventions.
Practices worth building into a routine:
- Keep
README,CONTRIBUTING, andLICENSEcurrent as the project evolves - Provide issue and pull request templates so incoming reports and changes arrive with the right information
- Delete branches after they're merged instead of letting them accumulate
- Archive repositories that are no longer maintained, so their read-only status is explicit rather than implied
- Review the community standards checklist GitHub surfaces for public repositories
⚠️ Exam Trap: Archiving a repository doesn't delete it — it makes the repository read-only (no new issues, pull requests, or commits) while keeping it fully visible and clonable. That's different from deleting a repository outright.
Reflection Question: A public repository hasn't been updated in three years and the maintainer has moved on. What does archiving it communicate to visitors that simply leaving it alone doesn't?
