...

At the Apache Software Foundation, governance emerges from collaboration, not authority. Projects thrive when contributors make decisions together, in public, and with respect for different perspectives. Votes confirm the consensus that has already been built on the mailing list. This  This is the culture that enables hundreds of Apache projects to evolve independently while sharing a common foundation: The Apache Way.

In the Incubator, podlings turn those principles into daily habitslearn to apply these principles in everyday practice. Mentors help guide communities transition as they move from informal decision-making to public, transparent discussions; decisions to open discussion, from individual initiative effort to collective shared ownership; and from mentor guidance to , and ultimately toward the self-governance , as exemplified by the expected of an Apache Project Management Committee (PMC).

This guide shows how ASF culture is applied in practice. It covers how projects:

• build and record consensus through discussion and voting;

• develop trust through contribution and transparency (“trust through contribution”);

• handle conflict constructively and inclusively;

• balance independence with accountability; and

• protect user trust through privacy, branding, and policy awareness.

The examples and scenarios are anonymized composites drawn from based on more than a decade of real ASF experiences drawn from public mailing lists.. They illustrate what works, what doesn’t, and how communities learn by doing, from unclear votes to mentor disengagement to cultural misunderstandings.

Who this is for.: Mentors, PPMC members, podling contributors, and future PMC members who want practical, copy-and-paste seek practical guidance rooted in ASF norms.

What this is not.: A policy manual. Authoritative Official ASF policies are available on ASF sites, focusing published elsewhere; this guide focuses on how to apply them in everyday project work.

Each discussion, vote, and release presents an opportunity to practice these values, build trust through contribution, and help a project evolve into a sustainable Apache community.

...

• Read actively: Pause at the reflection questions and consider how your project would respond.
• Discuss with others: Share scenarios or questions on your project’s dev@ list, and consensus grows through conversation.
• Connect the dots:  Link what you learn here with related materials: ASF Values, Governance  Governance in Practice, Voting & Consensus in Practice, Mentor Training, , Vendor Neutrality, Branding & Identity, Graduation Criteria and Graduation & Beyond.
• Apply it immediately: Try one improvement in your project’s process, for example, a clearer vote summary or a more inclusive discussion pattern.

...

All examples and scenarios in this guide are anonymized composites drawn from public ASF mailing list discussions and Incubator reports. They reflect real challenges and lessons learned, without naming specific projects or individuals. This respects community members’ privacy, avoids singling out mistakes, and keeps the focus on learning and shared improvement. The Incubator values open discussion along with compassion , empathy, and respect for volunteers who are learning The Apache Way through experience.

...

Voting and Consensus

Voting and consensus are at the heart of how Apache communities make decisions. At the ASF, a vote is not just a tally of +1s, it is the visible record of discussion, agreement, and shared responsibility. Healthy projects use voting to confirm consensus, not to replace it.

...

"If there are no objections within 72 hours, we’ll we will proceed with the merge."

After three days, one mentor, who had been travelling, objected, saying the merge introduced licensing complications. By then, the code had already been merged and discussed in other channels. The mentor felt ignored, while the community felt blindsided by the late objection. The thread devolved into arguments about whether the decision was final and who had the right to reopen it.

Reflection questions

1. What caused confusion about the lazy consensus process?
2. How should the community respond when an objection comes after action has been taken?

...

• Reopen discussion to consider the objection and, if needed, revert the change.
• In future, clearly state objection periods and follow up with a “no objections received” message to confirm consensus.
• Mentors can model good practice by keeping both decisions and closures visible on the mailing listposting brief summary messages that confirm the outcome of lazy consensus discussions.

...

Scenario: Ambiguous Vote Scope

...

"[VOTE] Approve architecture changes to support for a new storage backend"

Some contributors treated it as a binding decision vote, while others saw it as an informal consensus check. After tallying the votes (+5, 0, -1), disagreement broke out over whether the result was binding and who counted as eligible voters. The ambiguity created mistrust; some thought the -1 blocked progress, while others argued it was only advisory.

...

1. What steps could the PPMC have taken before starting the vote to make its scope and eligibility clear?
2. How can mentors model and teach consistent ASF voting practices to prevent confusion like this?

Possible path forward

• The mentor should can encourage the community to pause and revisit the discussion before treating the vote as final.
• Remind the podling that consensus comes first, votes are used to confirm shared understanding, not to decide by majority.
• For future threads, use clear subject tags and intent markers:
  • [DISCUSS] for exploration and consensus building
  • [VOTE] once agreement has been reached and the community is ready to record it
  • [RESULT] to summarize the outcome and next steps
• Encourage the PPMC to document when and how formal votes are used; discussion first, vote secondtheir own conventions for using formal votes, emphasising that discussion precedes votes and confirms consensus.

...

Scenario: Cross-List Release Vote Confusion

A podling successfully held a release vote on its own dev@ list, reaching four binding +1s and no objections. Believing it was complete, the release manager published the artifacts and announced the result. A few days later, an IPMC member noticed the vote had never been mirrored to the general@incubator list for IPMC review and approval. The vote had to be repeated, and the release was withdrawn until the second round was completed.

Reflection questions

1. Why is it important to hold Incubator release votes on both the podling and general@ listspodling’s dev@ list and the general@incubator list?
2. How can mentors and PPMCs communicate clearly about which steps are required before declaring a vote result final?

...

• Retract the published release and announce the correction openly, explaining that the IPMC vote was missed.Restart the vote following the proper procedure: first on the podling’s dev@ list, then on the general@incubator list once the first vote passes.
• Restart the vote on the dev@ list, then repeat it on general@incubator once the first passes.
• Update the release checklist so both steps happen before announcing the result.

...

Scenario: The Off-List Decision

A podling’s contributors agree discussed and agreed in a GitHub issue to change the project’s API design. The discussion seems appears to be settled, as everyone active on the repository has approved the change, and the pull request is has been merged. A week later, a mentor notices there was no corresponding discussion or record on the dev@ list. When the topic is raised, some participants argue that “it was already agreed on in GitHub comments.” Others had never seen the conversation and felt excluded. The mentor explains reminds the community that ASF decisions must need to be made discussed and visible on the project’s public mailing list, not only in tools or private channels.

...

A podling has been active for several months, with regular commits, discussions, and releases. However, one of its listed mentors hasn’t posted to the mailing list in nearly half a yearfor nearly six months. When the quarterly report is due, the remaining mentors realize they’ve been the only ones signing off. The absent mentor’s name is still listed, but they haven’t responded to pings or voted on any releases.

...

One mentor has become the de facto leader of a podling. They initiate most discussions, determine priorities, and frequently merge pull requests without waiting for community review. Although everything functions appears to run smoothly, other contributors are increasingly have become hesitant to disagree or propose suggest alternatives. The mentor’s good intentions have created quiet dependence rather than community independence.

...

During a disagreement over release timing, a mentor tells the podling to “wait for my approval before proceeding.” Several PPMC members feel uneasy, they . They thought the project was supposed to be self-governing.
The mentor later explains they only meant to ensure the ASF policy was followed, but the tone created confusion about authority.

...

Several active PPMC members work for the same company that initially proposed the podling. As the project matures, company goals begin start to align with influence community priorities, such as marketing deadlines, roadmap direction, or product integration timelines. Decisions on the dev@ list often mirror internal discussions, and other contributors hesitate to question them. When a mentor raises this concern, the PPMC insists that “everyone agrees internally,” but little discussion happens in public.

...

• Encourage all technical and strategic discussions to take place publicly on the mailing list, regardless of any prior internal agreements.
• When posting on behalf of an employer, clarify whose view you represent and invite others to comment openly.
• Rotate release managers, vote initiators, and report drafters to ensure shared ownership beyond a single organization.
• Mentors can remind the community that ASF projects operate by public consensus, not by company alignment, corporate . Corporate support is welcome, but direction comes from the community.
• If necessary, the PPMC or IPMC can invite new contributors from outside the company to broaden participation and strengthen neutrality.

...

During several community discussions, a mentor and two PPMC members consistently argue for a particular technical direction. Later, it is discovered that all three work for the same company, which plans to integrate the feature into its product. Their affiliation wasn’t hidden, concealed but it was never clearly stated in the relevant threads or votes. New contributors assumed the support was broad and independent. When this is raised, the individuals insist they were “just speaking as community members.” The incident damages trust and prompts a wider discussion about disclosure and transparency.

...

A podling submits its quarterly report, describing the community as “active and healthy,” which highlights several releases and broad participation. Mentors and IPMC members, however, are aware that mailing list traffic has decreased, and contributor engagement has been inconsistent. When asked, the PPMC explains that they “didn’t want to sound negative” in a public report. Mentors remind the community that reports are not public relations statements, ; they are a core part of the ASF’s oversight and learning process.

Reflection questions

1. Why must podling reports reflect reality, not just optimism?
2. What responsibilities do mentors and the PPMC share for ensuring accurate reporting?
3. How can mentors help communities be open about problems without fear of criticism?

...

In one podling, contributors became frustrated when requests for setting to set up mailing lists and publishing websites publish the website took longer than expected. Some members complained that ASF Infrastructure was “blocking” progress and proposed creating external systems to work around delays. Mentors reminded the community that ASF Infrastructure is a shared service supporting all projects.

...