File: MAINTAINERS_RULES.md

package info (click to toggle)
notary 0.6.1~ds1-3
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 4,692 kB
  • sloc: python: 1,112; sh: 481; makefile: 181; sql: 155
file content (39 lines) | stat: -rw-r--r-- 2,380 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# Maintainers Rules

This document lays out some basic rules and guidelines all maintainers are expected to follow.
Changes to the [Acceptance Criteria](#hard-acceptance-criteria-for-merging-a-pr) for merging PRs require a ceiling(two-thirds) supermajority from the maintainers.
Changes to the [Repo Guidelines](#repo-guidelines) require a simple majority.

## Hard Acceptance Criteria for merging a PR:

- 2 LGTMs are required when merging a PR
- If there is obviously still discussion going on in the PR, even with 2 LGTMs, let the discussion resolve before merging. If you’re not sure, reach out to the maintainers involved in the discussion.
- All checks must be green 
    - There are limited mitigating circumstances for this, like if the docs builds are just broken and that’s the only test failing.
    - Adding or removing a check requires simple majority approval from the maintainers.

## Repo Guidelines:

- Consistency is vital to keep complexity low and understandable.
- Automate as much as possible (we don’t have guidelines about coding style for example because we’ve automated fmt, vet, lint, etc…).
- Try to keep PRs small and focussed (this is not always possible, i.e. builder refactor, storage refactor, etc… but a good target).

## Process for becoming a maintainer:

- Invitation is proposed by an existing maintainer.
- Ceiling(two-thirds) supermajority approval from existing maintainers (including vote of proposing maintainer) required to accept proposal.
- Newly approved maintainer submits PR adding themselves to the MAINTAINERS file.
- Existing maintainers publicly mark their approval on the PR.
- Existing maintainer updates repository permissions to grant write access to new maintainer.
- New maintainer merges their PR.

## Removing maintainers

It is preferrable that a maintainer gracefully removes themselves from the MAINTAINERS file if they are
aware they will no longer have the time or motivation to contribute to the project. Maintainers that
have been inactive in the repo for a period of at least one year should be contacted to ask if they
wish to be removed.

In the case that an inactive maintainer is unresponsive for any reason, a ceiling(two-thirds) supermajority
vote of the existing maintainers can be used to approve their removal from the MAINTAINERS file, and revoke
their merge permissions on the repository.