Voting and Consensus in Practice

Turning Discussion into Transparent Decisions

Why Consensus Matters

  • Consensus is the foundation of ASF governance.

  • Formal votes are just one way of measuring it.

  • Discussion and shared understanding build trust and transparency.

Principles of Consensus Building

  • Community Over Code: decisions belong to the community, not individuals or companies.

  • Meritocracy: every voice matters; influence is earned through constructive contribution.

  • Transparency: decisions are made publicly on the project mailing list.

  • Respect and Inclusiveness: dialogue and differing views strengthen decisions.

In Practice

  • Start discussions seeking broad agreement not votes.

  • Encourage participation and document differing views.

  • Use a vote when consensus isn’t clear, or when a formal record improves transparency.

Forms of Consensus

  • Lazy Consensus - default for routine actions

  • Consensus After Discussion — used when objections arise

  • Formal Votes - required for binding ASF decisions

Lazy Consensus

  • The default ASF decision model.

  • A proposal is posted; if no one objects within 72 hours, it’s approved.

  • Works well for routine or low-risk actions like website or documentation updates.

  • Encourages forward progress without bureaucracy.

Example: “I’ll merge this pull request in 72 hours unless anyone objects.”

Consensus After Discussion

  • Used when objections arise.

  • Discuss until all significant concerns are addressed.

  • Aim for rough consensus, broad agreement, even if not everyone fully agrees.

  • Summarize the final outcome publicly.

Formal Votes

  • Used when ASF policy or legal requirements require a clear decision.

  • Common examples:

    • Code releases

    • Adding committers or PPMC members

    • Podling graduation proposals

  • Held on the correct list:

    • dev@ for community matters

    • private@ for personnel matters

  • Vote options: +1 approve, 0 abstain, -1 disapprove (with explanation)

  • A vote can be withdrawn and restarted if significant issues are found during discussion.

Release Voting in the Incubator

  • Two-stage process:

    • 1. PPMC vote on dev@ to confirm podling consensus.

    • 2. IPMC vote on general@ for ASF-level approval.

  • IPMC votes are binding; at least three +1s required.

  • Mentors ensure both votes are clearly linked and summarized.

Who Can Vote and When

DecisionWho VotesBindingMailing List

Routine actions

Anyone

No

dev@

Add committers

PPMC

PPMC

private@

Add PPMC members

PPMC

PPMC

private@

Releases

PPMC & IPMC

IPMC

dev@ → general@

Graduation

PPMC & IPMC

IPMC

general@

Best Practices for Healthy Consensus

  • Start with discussion, not a vote.

  • Summarize the decision clearly afterward.

  • Encourage participation from new contributors.

  • Welcome different perspectives.

  • Treat -1 votes as opportunities to improve.

  • Avoid a “vote-first” culture.

  • Watch for dominance by one company or mentor.

  • Assume good faith.

Recording Votes

  • Post a clear closing summary:

    • Separate binding and non-binding votes.

    • Include the outcome (e.g., “Passed with 3 binding +1s, no objections”).

    • Link to the original discussion thread.

  • Only votes on ASF-managed mailing lists are valid.

  • Use [DISCUSS], [VOTE], and [RESULT] tags for clarity in archives.

Consensus vs. Majority Rule

  • ASF decisions are based on consensus, not simple majority.

  • The goal is broad agreement and resolved objections.

  • Votes confirm consensus, they don’t replace discussion.

Typical Vote Duration

  • Minimum of 72 hours for most votes.

  • Longer for complex or contentious topics.

  • Ensures global participation across time zones.

Mentor Role in Consensus Building

  • Ensure decisions are made publicly and transparently.

  • Guide podlings on when formal votes are required.

  • Help communities avoid private decision-making.

  • Model respectful, inclusive discussion.

  • Step back as the community learns to self-govern.

Escalation and IPMC Support

  • If consensus breaks down or process is unclear, mentors can ask for IPMC guidance on general@.

  • The IPMC provides advice and oversight, not control.

  • The goal is to help podlings learn and apply ASF practices confidently.

Common Anti-Patterns

PatternProblemBetter Practice

Private chat decisions

Excludes community

Move all decisions to dev@

Corporate block votes

Undermines meritocracy

Encourage individual voices

Silence = agreement

Masks confusion/apathy

Ask for feedback explicitly

Vote before discussion

Misses perspectives

Start with open dialogue

Ignoring −1 votes

Breaks trust

Discuss and resolve before proceeding

Consensus and Graduation

  • Effective consensus building demonstrates community maturity.

  • Graduation indicators include:

    • Open, respectful discussions.

    • Participation from multiple organizations.

    • PPMC independently handling committer and PPMC additions.

    • Mailing-list record showing inclusive dialogue.

Mentor Takeaways

  • Encourage discussion before votes.

  • Ensure decisions are visible and well-documented.

  • Confirm both PPMC and IPMC release votes occur and are linked.

  • Use [DISCUSS], [VOTE], and [RESULT] tags for clarity.

  • Model patience and inclusion in every decision.

  • Step back as the podling grows toward independence.

Key Takeaway

  • Consensus is conversation first, voting second.

  • Healthy communities:

    • Discuss openly

    • Document clearly

    • Include all voices

    • Build trust through transparency