A Disorganized List of Maintainer Tasks
After I became a maintainer of Flask, I had to figure out a lot on my own. I didn't get an instruction manual. I know I won't have the same amount of time to devote to open source forever, and I don't want to leave the rest of the team in the same spot I was. I don't plan to leave, but documentation is helpful regardless.
If you think about maintaining a project, you probably expect to be reviewing and merging PRs, fixing and closing issues, and making new releases. That's hard all on its own! You need to become familiar with an entire codebase, and be confident enough about what you know to make decisions. But there's a whole other set of things you need to learn and do that no one really talks about, tools, processes, communication, community, documentation, and more.
I want to produce that instruction manual, "Every Maintainer Task and How to Do It". I figured this out, so other maintainers shouldn't have to, or should at least be able to get a head start.
I started writing down at least the different topics. When I mentioned this on Mastodon, people wanted to see the list, even without details. Here's a list of things I could think of off the top of my head that I either deal with or need to figure out. It's disorganized. It's incomplete. It's a start.
- Set up a dev container configuration as a contributor environment
- Create issue and pull request templates
- Create issue forms instead of templates
- Moderate issues and discussions
- Create an editorconfig for consistent text editing
- Set up pre-commit, pick out hooks, keep them updated
- Chat, do you use Discord, Zulip, Matrix, IRC, a combination, a bridge?
- Answer questions on GitHub discussions, chat, Stack Overflow
- A website, release announcements, blog
- Turning questions and answers into documentation improvements.
- Documentation translations, keeping synchronized, finding and retaining translators
- Documentation versions links to current stable version
- How to get and manage funding. We use PSF fiscal sponsor, GitHub Sponsors, TideLift, and EthicalAds.
- Using funds, paying maintainers, bounty levels on issues
- Knowing the scope of your project, saying no to requests, shared understanding between maintainers
- Code of conduct baseline, moderation beyond that
- Shared email for contact, moderation, security
- Ongoing communication between contributors and maintainers
- GitHub permissions, teams
- Read the Docs project owners
- PyPI owners, organization, trusted publishing
- Maintaining the ecosystem beyond the core libraries, community maintained projects
- Template repository, make all projects use same layout, tools, and processes
- Improve test coverage, organization, style
- Evaluate security emails, GitHub advisories, review CVEs
- Improve PRs, rebase to retarget branch, squash work commits, fix changelog/docs style, add tests, etc.
- How much work do you put into helping someone else make a PR vs doing it yourself?
- Automate release process, document manual process
- Keep up to date with Python changes, update tox/CI versions
- Keep up to date with tool/dependency changes
- License year is not needed/does not need to be updated
- Deprecations, warnings, removals, messaging about pinning versions and testing
- Supported versions policy, for bugs, for security, for Python, for dependencies
- Meetups, talk mentorship, conferences
- Collecting and listing resources
- Running sprints at conferences
I feel overwhelmed looking at this list, both in the amount I need to deal with and the amount that I need to document. I've probably missed things, and it doesn't even include writing code or making releases. Next time you want to ask "When's the next release?", instead look at the project and see where you can start getting involved. The more help maintainers have, the more they can get done.