| --- | |
| title: Decision-Making | |
| --- | |
| 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][14] (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 at a | |
| decision, or at least a compromise, that everyone can live with. | |
| ## Lazy Consensus | |
| [Lazy consensus][10] 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][14] 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. | |
| [10]: https://www.apache.org/foundation/glossary.html#LazyConsensus | |
| [11]: /committers/consensusBuilding.html | |
| [14]: https://www.apache.org/foundation/voting |