The most important thing about engaging with any Apache project is that everyone is equal. All project participants with an opinion can express that opinion and, where appropriate, have the community consider it.
To some, the idea of having to establish consensus in a large and distributed team sounds inefficient and frustrating. Don’t despair, though: The Apache Way has a set of simple processes to ensure things proceed at a good pace.
In ASF projects we don’t like to vote. We reserve that for the few things that need official approval for legal or process reasons (e.g. approving a release or adding a new committer). Most of the time we work with the consensus-building techniques documented below.
Consensus ¶
The word “consensus” is a bit ambiguous in English, and so can lead to some misunderstandings of intent when we use it in the context of project decisions. Consensus does not mean that everyone agrees on all details. Rather, it means that the project, as a whole, has arrived a decision, or at least a compromise, that everyone can live with.
Lazy Consensus ¶
Lazy consensus is the first, and possibly the most important, consensus-building tool we have. Essentially lazy consensus means that you don’t need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.
Lazy consensus is achieved by stating your intent on a public email, and waiting an appropriate amount of time (usually 72 hours) for anyone to object. Silence indicates consent, and after that time has passed, you can assume that nobody objects, and proceed with your plan.
Objections to the plan should be accompanied by a legitimate reason, and be open to discussing possible alternative approaches.
Consensus Building ¶
Sometimes lazy consensus is not appropriate. In such cases it is necessary to make a proposal to the email list and discuss options. There are mechanisms for quickly showing your support or otherwise for a proposal and building consensus within the community.
A consensus-building thread is often indicated by a subject line starting with [DISCUSS]. Sufficient time should be provided for members of the community to express opinions, and defend objections.
It is customary for the initiator of the discussion to post a summary of the discussion once it appears that consensus has been reached, to ensure that their understanding of the will of the community is accurate.
Voting ¶
Occasionally a “feel” for consensus is not enough. Sometimes we need to have a measurable consensus, for example, when voting to add committers or to approve a release.
To conduct a vote once a discussion thread seems to be winding down, start a new thread with a subject line starting with [VOTE] to indicate that a formal vote has been requested.