...
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.
- Consensus Approval – Consensus approval requires 3 binding +1 votes and no -1 votes (vetoes).
- Majority Approval – requires Requires at least 3 binding +1 votes more +1 votes than -1 votes.
- Lazy Consensus – consensus 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.