DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
This guide explains how decision-making works in Apache communities, especially within Incubator podlings. Consensus is the foundation of governance at the ASF, formal votes are only one way of measuring it.
Understanding when and how to use discussion, lazy consensus, and formal votes helps ensure decisions are transparent, inclusive, and aligned with The Apache Way.
1. Principles of Consensus Building
- Community Over Code: decisions belong to the community, not to individuals or companies.
- Meritocracy: everyone’s voice matters; greater influence is earned through sustained, constructive contribution.
- Transparency: decisions are made publicly on the project mailing list.
- Respect and Inclusiveness: open discussion and differing perspectives strengthen consensus. It’s built through dialogue, not uniformity.
In practice:
Every discussion starts by seeking broad agreement rather than counting votes. Encourage participation and document differing views. Use a vote when consensus isn’t clear, or when formally recording the community’s agreement aids transparency and traceability.
2. Forms of Consensus
2.1 Lazy Consensus
The most common ASF decision pattern.
A proposal is posted; if no one objects within a stated time (typically 72 hours), it is considered approved.
- Works well for routine actions (website updates, dependency upgrades, documentation improvements).
- Encourages quick progress without unnecessary bureaucracy.
- Anyone can still object and trigger deeper discussion.
Example:
“I’ll merge this pull request in 72 hours unless anyone objects.”
2.2 Consensus After Discussion
When objections arise, discuss until all major concerns are addressed. Adjust the proposal to accommodate feedback where possible.
- Aim for “rough consensus”, not unanimity, but general support with no unresolved strong objections.
- Summarize the outcome on the mailing list so it’s part of the public record.
- Remember that strong projects welcome open dialogue and disagreement as part of the path to alignment.
2.3 Formal Votes
Formal votes are used when ASF policy or legal requirements demand a clear decision.
Common examples:
- Code release votes
- Adding committers or PPMC members
- Podling graduation proposals
Votes are held on the appropriate mailing list (dev@ for community matters, private@ for personnel).
Each binding voter (PPMC or IPMC member, depending on the vote) replies with:
+1Approve0Abstain-1Disapprove (with explanation)PPMC votes are binding for adding new committers and PPMC members.
Release votes follow a two-stage process:
- The first-stage vote takes place on the podling’s
dev@list, where the PPMC reviews and votes on the release. - If approved, a second-stage vote is held on the general@ incubator list for IPMC approval. Only IPMC member votes are binding at this stage, and their approval is required before the release may be published.
- The first-stage vote takes place on the podling’s
Graduation votes are also held on
general@and require IPMC binding approval.Community members can always vote or comment to share their opinions and help build consensus, even if their votes are non-binding.
A
-1vote signals concern that should be discussed and resolved, it’s part of dialogue, not a rejection of people or effort.
IPMC Oversight
The Incubator PMC (IPMC) provides oversight on behalf of the ASF Board during a project's incubation period. PMC votes on releases and graduations, which is how this oversight is exercised. Once a project graduates, those decisions are made entirely by its own PMC.
3. Who Can Vote and When
| Type of Decision | Who Votes | Binding? | Where |
|---|---|---|---|
| Routine actions | Anyone | Informal | dev@ |
| Adding committers | PPMC members | Yes (PPMC) | private@ |
| Adding PPMC members | PPMC members | Yes (PPMC) | private@ |
| Releases | PPMC and Mentors / IPMC | Yes (IPMC) | dev@ → general@ |
| Graduation | PPMC → IPMC | Yes (IPMC) | general@ |
Releases in the Incubator use a two-stage voting process:
- The PPMC conducts the initial vote on the podling’s
dev@list to confirm community consensus. - The IPMC holds the binding vote on the
general@incubator.apache.orglist to approve the release for publication.
Mentors should ensure both votes are clearly recorded, include accurate tallies of binding and non-binding votes, and link the dev@ result when starting the IPMC vote thread for transparency.
4. Best Practices for Healthy Consensus
- Start with discussion, not a vote. Explain the problem and seek input first.
- Summarize the outcome. After any vote or discussion, record the decision on the list for future reference.
- Encourage participation. Invite new contributors to share their perspectives.
- Welcome differing views. Open discussion strengthens decisions; don’t rush to closure.
- Document objections respectfully. Disagreement is part of the process, not a personal conflict.
- Use votes wisely. They help confirm and record consensus when the discussion concludes or when clarity is needed.
- Avoid “vote first” culture. Votes without discussion often signal poor engagement.
- Watch for imbalances. If one mentor or vendor dominates voting, pause to re-examine how decisions are being made.
- Assume good faith. Differences of opinion are normal and respectful dialogue keeps the community healthy.
5. Additional Notes and Tips
Non-Binding Votes
Non-binding votes (from contributors, committers, and community members) do not carry legal weight but are valuable indicators of engagement and shared ownership.
They demonstrate community participation and help mentors and the IPMC assess whether a podling’s community is active, healthy, and inclusive.
Recording Vote Results
When closing a vote, post a clear summary listing binding and non-binding votes separately.
Include a short outcome statement (e.g., “The vote passed with 3 binding +1s and no objections”), and link to the discussion thread.
This helps future reviewers, mentors, and auditors easily locate the record of decisions.
Only votes made on official ASF-managed mailing lists are recognized as valid.
Off-list or private votes should never happen and all decision-making must be visible to the community.
Consensus vs. Majority Rule
ASF decision-making is based on consensus, not simple majority.
The goal is to reach broad agreement and address concerns through discussion.
Votes help confirm that consensus, but they do not replace dialogue and understanding.
Typical Vote Duration
Standard ASF and Incubator practice allows at least 72 hours for most votes.
This ensures all participants across time zones have the opportunity to review and respond.
Longer periods are encouraged for complex or contentious proposals.
6. Mentor Role in Consensus Building
Mentors help ensure podlings:
- Make decisions publicly and transparently.
- Understand when formal votes are required.
- Engage community members early in the discussion.
- Avoid private or off-list decision-making.
- Learn that healthy consensus welcomes open dialogue and differing perspectives.
- Recognize that votes can help confirm and document community agreement when discussions reach alignment.
- Guide without steering. Mentors enable the community to make its own decisions.
Escalation and IPMC Support
If consensus breaks down or a podling is unsure about the process (for example, during release or personnel votes), mentors may request guidance from the IPMC on general@incubator.apache.org.
The IPMC’s role is advisory and oversight-based, helping the community learn ASF practices without making decisions on its behalf.
Mentors as Bridges
Mentors act as bridges between the podling and the broader ASF community, helping translate ASF expectations and ensuring that podling practices remain aligned with Foundation policies throughout incubation.
Mentors should model good practice. They should explain reasoning, clarify ASF norms, and gently guide PPMC discussions when votes are misused or rushed.
7. Common Anti-Patterns
| Pattern | Why It’s a Problem | Better Approach |
|---|---|---|
| Private decisions in chats | Excludes community and violates transparency | Move all decisions to dev@ |
| Corporate block voting | Undermines meritocracy | Encourage individual voices |
| Silence misread as agreement | May hide confusion or apathy | Actively invite feedback |
| Vote without discussion | Misses perspectives | Start with open dialogue |
Ignoring -1 votes | Breaks trust | Address and resolve concerns before proceeding |
8. Tying Consensus to Graduation
Demonstrating effective consensus building is part of showing community maturity. The IPMC and Board look for evidence that the podling can govern itself independently.
Graduation indicators:
- Decisions made through open, respectful discussion.
- Active participation from multiple organizations.
- PPMC independently handling committer and PPMC additions.
- Mailing-list record showing healthy, inclusive dialogue.