prometheus / prometheus/node_exporter
Define some light-weight maintainer processes
@discordianfish is already working on this.
Since Aug 18, 2018.
- Dominant language
- Go
- Stars
- 13.8k
- Forks
- 2.7k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 8
Description
I'd like to establish some light weight process how we handle issues and PRs. If we agree on those, I'll submit a PR to include this in CONTRIBUTING.md. I believe those simple changes will reduce frustration a lot, speed up time to resolve PRs and issues and ultimately save us time.
Issues
- Someone opens new issues
- Maintainer reviews issue and either:
- closes it
- asks for clarification and sets tag 'require/feedback'
- sets tag 'accepted' and optionally further tags for grouping (bug/feature collector/foo)
PRs
- Someone submits new PR
- If fix for existing issue, mentions 'closes #'
- If not it must include a short description why the change should be in the node-exporter (basically what otherwise would be explained in an issue)
- Specific maintainers but also any other person may be pinged to review, but this is not required
- (We actively monitor for active pull requests / get notified. We might have to change this if nobody feels responsible to review pending PRs, but would discuss this later)
- We use the review feature to request changes or approve PRs
- If a maintainer wants to close a PR because it's out of scope etc, they comment and tag as
pending/close - Two reviews are required for a PR to get merged but only one person needs to be a maintainer, the other one should be familiar with the node-exporter though
Releases
Mostly TBD but...
- Create a new milestone for every release
- Tag the PRs and issues that should be included
Auto closing of issues
Not sure if this is necessary right now, but we might start testing it
- Issues get closed if in 'require/feedback' for more than 30 days
- PRs get closed if changes are requested but the PR is not updated for 30 days
- PRs get closed if no changes are requested but it's not approved/merged within 90 days (this should never happen, but it forces us to decide something within 90 days)
All those deadlines can be extended by commenting on the issue.
Automation
At some point I'd like to automate most of this, for now though I would just follow it manually.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.