Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is one suggested model, note that (P)PMCs have some leeway in the way decisions are made, where vetoes apply etc., see https://httpd.apache.org/dev/guidelines.html and http://couchdb.apache.org/bylaws.html#decisions for good examples of that. For CouchDB note that nowadays the term "community guidelines" is preferred over bylawxsbylaws.

Different decisions require different forms of approval but community consensus is always the goal. Voting when needed, should be open for at least 72 hours.

  • Lazy Consensusconsensus Consensus no objections (‘silence gives assent’).

Action

Who can vote

Approval

Where to vote

Board approval required

Code change

Committer

Lazy Consensus

public dev or commit list


Release

PMC

Majority Approval

public dev list


New committer

PMC

Consensus Approval or other documented method4

private list


New PMC member

PMC

Consensus Approval

private list

Yes1

Existing committer removal

PMC

Consensus Approval

private list


Existing PMC removal

PMC

Consensus Approval

private list

Yes2

Change chair

PMC

Consensus Approval

private list

Yes3

1 Notice must be given to the board, or if a podling the IPMC.

2 Except for the PMC member in question. Only the board can remove PMC members.

3 Needs to be approved by the board at the next board meeting.

4 While most project projects vote on new committers, it's up to the PPMC to decide how to do it.