You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

STATUS: UNRATIFIED DRAFT

Fundamental Tenets:

  • Follow the Apache Code of Conduct
  • Behave as you would in a professional context
  • Assume positive intent
  • Assume others are correct; always respond to your best possible interpretation of their statements, and seek clarification where this is difficult
  • These guidelines are predicated on actors behaving reasonably
  • Disagreements on any matter (including vetoes) can be escalated to the PMC, but this is strongly discouraged and suggests a breakdown of these tenets

pmc responsibilities and forums of discussion:

Guiding philosophies: Default to dev list and “decide as a community”. Favor pmc minimalism.

On private@:

  1. Enforcing trademark
  2. Votes on new committers (super majority)
  3. Votes on new pmc members (super majority)
  4. Security issues

On dev@:

  1. Discussion / binding votes on releases (Consensus: min 3 PMC +1, no -1)
  2. Discussion / binding votes on project structure and governance changes (adopting subprojects, how we vote and govern, etc). (super majority)

Discussion:

  1. All proposals starts with a [DISCUSS] thread to reach a community consensus
  2. [DISCUSS] threads resolve areas of dispute via initial argumentation, that should be as concise as possible to leave room for all topics. Non-binding polls should be conducted on areas without clear consensus, to help provide some from the silent majority.
  3. [DISCUSS] threads are closed once consensus is reached via declared lazy consensus with a 1 business day notice period.
  4. In the event of a stall, informal votes to gauge community sentiment may be conducted.

How we vote as a pmc:

Guiding philosophy: “Mindfully balance the need for progress with the need for consensus”

PMC roll call will be taken every 6 months. This is an email to dev@ w/the simple question to pmc members of “are you active on the project and plan to participate in voting over the next 6 months?”. This is strictly an exercise to get quorum count and in no way restricts ability to participate during this time window. A super-majority of this count becomes the low-watermark for votes in favour necessary to pass a motion, with new PMC members added to the calculation.

Any pmc vote on any of the issues above w/the exception of releases will be conducted as follows:

  1. A [DISCUSS] thread is conducted
  2. A [VOTE] thread is opened for a window, typically of one week. The window and method must be specified.


Simple majority voting: For all active participants, if +1 outweigh -1, vote passes.

Super majority voting: 66% of votes must be in favor to pass. Minimum participation #’s of active quorum is 66% of active quorum must cast a vote in favour for it to be considered valid.

How we vote as a community:

  1. Committer votes are considered “binding”
  2. Non-committer votes are important, encouraged, and considered advisory

For Code Contributions:

  1. Correcting typos, docs, website, and comments etc operate a “Commit Then Review” policy
  2. Code modifications must have been reviewed by at least one other contributor
  3. Code modifications require two +1 committer votes (can be author + reviewer)
  4. Code must not be committed while under active reasonable discussion
  5. Code must not be committed if a committer has requested reasonable time to conduct a review 
  6. Code must not be committed while subject to an explicit -1 vote by a committer for clearly expressed and reasonable technical grounds
  7. If code has been committed but not released, a -1 vote from a committer (that is not resolved by follow-up commits) can be reverted
  8. If the proposer responds to the concerns of a -1 voter, and the -1 voter does not engage reasonably with the response, the -1 is rescinded
  9. Committers should explicitly veto work exceptionally rarely


For CEP:

Guiding philosophy: encourage up front collaboration on potentially contentious proposals

  1. A small group of contributors works on a draft CEP before bringing it to the community.
  2. A [DISCUSS] thread is conducted on the proposal
  3. Once the proposal is finalized and any major committer dissent reconciled, call a [VOTE] on the ML to have the proposal adopted. The criteria for acceptance is consensus (3 binding +1 votes and no binding vetoes). The vote should remain open for 72 hours.
  4. Minor modifications to a CEP can be made by lazy consensus; major modifications should be made via this process, with the prior version being archived and linked from the new proposal.
  • No labels