Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • gitlab-org/build/omnibus-mirror/prometheus
1 result
Show changes
Commits on Source (2)
  • beorn7's avatar
    Updated according to code review comments · a89d4e83
    beorn7 authored 
    Please pay special attention to this commit as I mostly react to my
own comments (while also trying to incorporate results from wider
discussions).

In approximate order if importance:

- As per discussion, I made acceptance of new team mebers depend on a
  supermajority vote (while given special emphasis on the desire to
  reach consensus).

- As per discussion, I made maintainership independent from team
  membership, albeit explicitly called out as an exception. (I also
  mentioned the possible graduation path in the FAQ to illustrate how
  such an exception could look like.)

- Changes in maintainership are now by lazy consensus, but have to be
  announced on the dev list. That saves us the explicit mention of a
  conflict-resolving vote, as that's part of our definition of lazy
  consensus. Thanks to maintainership being independent from team
  membership, everything a rogue maintainer has done, can be reverted,
  so there is no need to become any more formal about changes in
  maintainership.

- Clarified that there are no “abstain” votes (which is relevant for
  the multi-option votes to determine majority).

- Fixed “at least half the votes” to “more than half”.

- Numerous typography (mostly Oxford comma and “proper quotes”) and
  spelling fixes (mostly favour -> favor, as we in general use
  American spelling).
    a89d4e83
  • beorn7's avatar
    Fix definition of maintainer · d49cecb1
    beorn7 authored
    d49cecb1
Hide whitespace changes
Inline Side-by-side
Showing
with 17 additions and 15 deletions
GOVERNANCE.md
View file @ d49cecb1
@@ -4,7 +4,7 @@ This document describes the rules and governance of the project. It is meant to
 
* **Team members**: Any members of the private [prometheus-team][team] Google group.
 
* **Maintainers**: Team members who are leads on an individual project ([MAINTAINERS.md][maintainers.md]).
* **Maintainers**: Maintainers lead an individual project or parts thereof ([MAINTAINERS.md][maintainers.md]).
 
* **Projects**: Any repository in the Prometheus [GitHub organization][gh].
 
@@ -12,7 +12,7 @@ This document describes the rules and governance of the project. It is meant to
 
## Values
 
The Prometheus developers and community are expected to follow the values defined in the [CNCF charter][charter], including the [CNCF Code of Conduct][coc]. Furthermore, the Prometheus community strives for kindness, giving feedback effectively and building a welcoming environment. The Prometheus developer community strives to operate by rough consensus for the majority of decisions and only resort to conflict resolution through a motion if consensus cannot be reached.
The Prometheus developers and community are expected to follow the values defined in the [CNCF charter][charter], including the [CNCF Code of Conduct][coc]. Furthermore, the Prometheus community strives for kindness, giving feedback effectively, and building a welcoming environment. The Prometheus developer community strives to operate by rough consensus for the majority of decisions and only resort to conflict resolution through a motion if consensus cannot be reached.
 
## Projects
 
@@ -24,9 +24,9 @@ Each project must have a MAINTAINERS.md file with at least one maintainer. Where
 
Team member status may be given to those who have made ongoing contributions for at least 3 months to the Prometheus Project. This is usually in the form of code improvements and/or notable work on documentation, but organizing events or user support could also be taken into account.
 
New members may be proposed by any existing member by email to [prometheus-team][team] and voted on by [lazy consensus](#consensus). If no consensus is reached, the new member is not accepted.
New members may be proposed by any existing member by email to [prometheus-team][team]. It is highly desired to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal [supermajority vote](#supermajority-vote).
 
Team members are added to the [GitHub organization][gh] and have commit rights to all projects. They should however respect the maintainers of each project.
Team members are added to the [GitHub organization][gh] as _Owner_. They should however respect the maintainers of each project.
 
Team members may retire at any time by emailing [the team][team].
 
@@ -40,11 +40,13 @@ A public list of team members is kept on the [community page][community] or link
 
### Maintainers
 
Maintainers are team members who lead one or more project(s) and serve as a point of conflict resolution amongst the contributors to this project.
Maintainers lead one or more project(s) or parts thereof and serve as a point of conflict resolution amongst the contributors to this project. Ideally, maintainers are also team members, but exceptions are possible for suitable maintainers that, for whatever reason, are not or not yet team members.
 
A maintainer or committer may resign by notifying the [team mailing list][team]. A maintainer with no project activity for a year is considered to have resigned. Maintainers who wish to resign are encouraged to propose another team member to take over the project.
Changes in maintainership have to be announced on the [developers mailing list][devs]. They are decided by [lazy consensus](#consensus) and formalized by changing the `MAINTAINERS.md` file of the respective repository.
Maintainers are granted commit rights to all projects in the [GitHub organization][gh].
 
An extraordinary change of maintainership of any project may be proposed on the [team mailing list][team] and is voted on by [majority vote](#majority-vote).
A maintainer or committer may resign by notifying the [team mailing list][team]. A maintainer with no project activity for a year is considered to have resigned. Maintainers who wish to resign are encouraged to propose another team member to take over the project.
 
A project may have multiple maintainers, as long as the responsibilities are clearly agreed upon between them. This includes coordinating who handles which issues and pull requests.
 
@@ -58,11 +60,11 @@ Technical decisions that span multiple parts of the Prometheus Project can be di
 
### Governance changes
 
Material changes to this document are discussed publicly on the [developer mailing mailing list][devs]. Any change requires a [supermajority](#supermajority-vote) in favour. Editorial changes may be made by [lazy consensus](#consensus) unless challenged.
Material changes to this document are discussed publicly on the [developer mailing mailing list][devs]. Any change requires a [supermajority](#supermajority-vote) in favor. Editorial changes may be made by [lazy consensus](#consensus) unless challenged.
 
### Other matters
 
Any matter that needs a decision, including but not limited to financial matters, may be called to a vote by any member if they deem it necessary. For financial, private or personnel matters discussion and voting takes place on the [team mailing list][team], otherwise on the [developer mailing list][devs].
Any matter that needs a decision, including but not limited to financial matters, may be called to a vote by any member if they deem it necessary. For financial, private, or personnel matters, discussion and voting takes place on the [team mailing list][team], otherwise on the [developer mailing list][devs].
 
## Voting
 
@@ -96,9 +98,9 @@ Majority votes must be called explicitly in a separate thread on the appropriate
 
Votes may take the form of a single proposal, with the option to vote yes or no; or the form of multiple alternatives.
 
A vote on a single proposal is considered successful if more vote in favour than against.
A vote on a single proposal is considered successful if more vote in favor than against.
 
If there are multiple alternatives, members may vote for one or more alternative, or vote "no" to object to all alternatives. A vote on multiple alternatives is considered decided in favour of one alternative if it has received the most votes in favour, and a vote from least half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
If there are multiple alternatives, members may vote for one or more alternative, or vote “no” to object to all alternatives. It is not possible to cast an “abstain” vote. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from more than half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
 
### Supermajority vote
 
@@ -106,9 +108,9 @@ Supermajority votes must be called explicitly in a separate thread on the approp
 
Votes may take the form of a single proposal, with the option to vote yes or no; or the form of multiple alternatives.
 
A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favour.
A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favor.
 
If there are multiple alternatives, members may vote for one or more alternative, or vote "no" to object to all alternatives. A vote on multiple alternatives is considered decided in favour of one alternative if it has received the most votes in favour, and a vote from least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
If there are multiple alternatives, members may vote for one or more alternative, or vote “no” to object to all alternatives. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from at least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.
 
## FAQ
 
@@ -120,9 +122,9 @@ Send an email to [the developer mailing list](devs) with your motion. If there i
 
### How do I become a team member?
 
To become an official team member, you should make ongoing contributions to one or more project(s) for at least three months. At that point, a team member (typically a maintainer of the project) may propose you for membership. The discussion about this will be held in private, and you will be informed privately when a decision has been made.
To become an official team member, you should make ongoing contributions to one or more project(s) for at least three months. At that point, a team member (typically a maintainer of the project) may propose you for membership. The discussion about this will be held in private, and you will be informed privately when a decision has been made. A possible, but not required, graduation path is to become a maintainer first.
 
Should the decision be in favour, your new membership will also be announced on the [developers mailing list][devs].
Should the decision be in favor, your new membership will also be announced on the [developers mailing list][devs].
 
### How do I add a project?