STATUS: Ratified 2020/06/25

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 majority of the electorate becomes the low-watermark for votes in favour necessary to pass a motion, with new PMC members added to the calculation. That is, both types of majority votes (simple and super-majority) require this 50% of last roll call participation.

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. Requires 50% participation of roll call.

Super majority voting: 66% of votes must be in favor to pass. Requires 50% participation of roll call.

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.


For Releases:

  1. Consensus: min 3 PMC +1, no PMC -1. These votes are neither Simple majority nor Super majority. Vetos are to be accompanied with (technical) rationale.
  2. More information on the release process and voting is in Release Managers Onboarding.


Subproject Governance

  1. The Apache Cassandra PMC is responsible for governing the broad Cassandra Ecosystem.
  2. The PMC will vote on inclusion of new interested subprojects using the existing procedural change vote process documented in the confluence wiki (Super majority voting: 66% of votes must be in favor to pass. Requires 50% participation of roll call).
  3. New committers for these subprojects will be nominated and raised, both at inclusion as a subproject and over time. Nominations can be brought to private@cassandra.apache.org. Typically we're looking for a mix of commitment and contribution to the community and project, be it through code, documentation, presentations, or other significant engagement with the project.
  4. While the commit-bit is ecosystem wide, code modification rights and voting rights (technical contribution, binding -1, CEP's) are granted per subproject
    1. Individuals are trusted to exercise prudence and only commit or claim binding votes on approved subprojects. Repeated violations of this social contract will result in losing committer status.
    2. Members of the PMC have commit and voting rights on all subprojects.
  5. For each subproject, the PMC will determine a trio of PMC members that will be responsible for all PMC specific functions (release votes, driving CVE response, marketing, branding, policing marks, etc) on the subproject.
  • No labels