prometheus / prometheus/node_exporter

Define some light-weight maintainer processes

Open
#383 4 comments 0 reactions 1 assignee View on GitHub

@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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.