The main duties
The maintainer is responsible for:
Repository ownership doesn’t mean that the owner needs to do all the required work, it means that they ensure the work gets done.
Responding to issues and pull requests
To set the expectations correctly, the maintainer will make sure that when an issue or a pull request is submitted, the issuer gets notified that a human has seen the submission and what happens next. This can mean:
- telling the consumer whether the issue/PR will be fixed/merged or not
- ETA of how long it will take until the next response or until the issue resolution/PR review
- asking for more details
Defining and communicating the vision
It’s necessary to clearly express what’s the future of the project. A good idea is to groom the backlog and decide on what the next major steps will be. A good tool to communicate the vision is the GitHub Milestones or GitHub Projects.
If the project is not to be maintained any longer, it’s necessary to archive it and ideally, add a disclaimer explaining why the repo is archived.
The first response time and any follow-up to a customer’s reply should not exceed 5 business days. If a reply will take longer, it’s necessary to update the expectation of the person waiting for the reply.
The resolution time depends on an actual issue/PR. Again, keep customer’s expectations about the resolution time up to date.
Keeping the repository in a good shape
The maintainer must ensure the repository is in a healthy state. This includes:
- the CI is present, running, and tests are passing
- there are no stale pull requests - they either get merged (after a review and testing) or closed
- the backlog of issues is accurate, up-to-date
- the issue is labeled correctly, the descriptions are sufficient for anyone from the community to pick them up and process
- the repo is well documented (READMEs and Wikis are up to date and correspond with the latest version)
- adherence to standards and platform idioms (e.g. semantic versioning, using the right code style, targeting the right platform versions, adhering to conventions)
- making sure obsolete and broken packages are marked as deprecated and unlisted from package repositories (such as NuGet, npm, etc.)
- adherence to internal standards checklist
Managing the releases and keeping them in sync with product development
The maintainer is responsible for making sure:
- critical issues get planned and addressed within the standard development process (e.g. bring issues to grooming/sprint planning)
- any product updates affecting the OS project get reflected (e.g. a new API endpoint should be reflected in SDKs and samples) - see New REST API feature for more information.
- versions of the OS project are being released regularly to reflect the needs of customers
The release process consists of two steps:
- Publishing new version on the package manager (.NET -> Nuget, node/js -> npm, …)
- Ensuring the proper announcement
- New feature is described in release changelog
- Decide whether to announce new version in product changelog/discord/newsletter
💡 Make your life easier
Many of the tasks can be automated - e.g. stale pull requests can be closed automatically, version management to be automated to a large extent, keeping things in sync with other systems like Jira can be automated. Be smart and automate!