How Apache Communities Learn to Govern Themselves

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 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 habits. Mentors help communities transition from informal decision-making to public, transparent discussions; from individual initiative to collective ownership; and from mentor guidance to self-governance, as exemplified by the 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 real ASF experiences. 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 guidance rooted in ASF norms.

What this is not. A policy manual. Authoritative policies live on ASF sites; this guide points to them and 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.

...

...

How to Use This Guide

...

These scenarios are based on real experiences from ASF projects and demonstrate how communities learn to strike a balance between efficiency, transparency, and trust.

...

Scenario

...

: Lazy Consensus Gone Wrong

A podling announced a major decision to merge two modules using lazy consensus. The email read:

...

• Reconfirm the change by summarizing the objection and reopening the discussion on the mailing list.
• Clarify future lazy consensus procedures by defining objection windows clearly (e.g., “no objections within 72 hours”) and sending a follow-up summary email stating when consensus was reached.
• Mentors can model good practice by posting clear “no objections received” messages when lazy consensus concludes.

...

Scenario

...

: Ambiguous Vote Scope

A PPMC launched a vote on the dev@ list with the subject line:

...

• The mentor should 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
• Mentors can guide the PPMC toward documenting their own conventions for when and how formal votes are used, reinforcing open discussion as the default.

...

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.

...

These scenarios illustrate common mentoring challenges and how mentors can support growth without taking control.

...

Scenario

...

: The Silent Mentor

A podling has been active for several months, with commits, discussions, and releases happening regularly. However, one of its listed mentors hasn’t posted to the mailing list in nearly half a year. 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.

...

• The active mentors should contact the silent mentor privately to confirm whether they wish to continue.
• If there’s no response, the PPMC can request that the IPMC retire the mentor and invite another with complementary skills.
• Encourage periodic mentor check-ins, even brief “+1, still here” notes help maintain trust and visibility.

...

Scenario

...

: The Over-Involved Mentor

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 smoothly, other contributors are increasingly hesitant to disagree or propose alternatives. The mentor’s good intentions have created quiet dependence rather than community independence.

...

• The mentor can step back deliberately, prompting others to lead discussions or manage releases.
• Rotate responsibilities so contributors gain experience in mailing list voting, reporting, and issue triage.
• Mentors can shift to a coaching stance, asking questions instead of providing answers, to encourage community initiative.

...

Scenario

...

: Unclear Boundaries Between Mentor and PPMC

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

...

In the Incubator, new communities often face their first challenges when personalities, priorities, or cultures clash. How these moments are handled can define the community’s tone for years to come. Mentors play a crucial role by modeling calm, transparent communication and ensuring all voices are heard.

...

Scenario

...

: The Heated Thread

A technical debate about the project’s build system becomes personal. Two contributors begin trading sharp remarks on the mailing list, each insisting their approach is correct. Other participants go silent, unsure how to intervene. After several days, the discussion ends abruptly, but one contributor stops participating altogether.

...

• Acknowledge the tension and steer the conversation back to technical facts rather than personalities.
• Remind participants that ASF discussions must remain respectful and public, focusing on ideas rather than individuals.
• Reach out privately (if appropriate) to the inactive contributor to check in and invite them back into a calmer, structured discussion.
• Summarize lessons learned in a closing email, showing transparency and reinforcing good communication norms.

...

Scenario

...

: Private Discussions and Missing Context

A small group of contributors regularly discuss project direction in a private chat channel. Decisions are sometimes made there, then later announced on the mailing list. Other community members feel excluded and confused, unsure how or when these decisions were made. When a mentor raises the issue, the group says, “We were just being efficient.”

...

• Encourage the group to summarize any private discussion on the mailing list, capturing the key points and rationale.
• Reinforce the ASF principle that “if it didn’t happen on the list, it didn’t happen.”
• Normalize brief summaries, even short recaps help keep everyone informed.
• Mentors can help set a respectful tone by acknowledging efficiency concerns but explaining the long-term value of public archives for learning and accountability.

...

Scenario

...

: Cultural Misunderstanding

A contributor from one region tends to write very brief, direct comments, which others interpret as rude or dismissive. In turn, they feel frustrated that their efficiency is being criticized. The mailing list begins showing subtle tension, with people responding less or avoiding reviews from that person. A mentor notices and suspects it’s more a cultural difference than a personal conflict.

...

These scenarios explore everyday situations where community health needs attention, and how mentors can help strengthen participation and sustainability.

...

Scenario

...

: The Single-Maintainer Risk

A podling’s activity appears strong, with regular commits, quick pull-request merges, and responsive issue triage; however, nearly all of it is coming from one person. That contributor is also the release manager and primary reviewer. When they take a short break, the project slows dramatically, and open PRs pile up.

...

• Identify areas where others can contribute, such as documentation, testing, website updates, or triage, to lower barriers to participation.
• Invite frequent contributors to take on small responsibilities, like summarizing votes or drafting reports.
• Use release and review rotations to build experience across multiple people.
• Mentors can highlight the ASF goal of “community over code”, long-term health depends on shared responsibility, not individual productivity.

...

Scenario

...

: The Employer-Dominated Podling

Most active committers on a podling are employed by the same company. Their employer provides infrastructure, funding, and time to work on the project, which has been essential to early success. However, external contributors have started to withdraw, saying they don’t feel their input is valued or that decisions are already made internally.

...

• Encourage the company to clarify that participation is open to all and decisions are made publicly.
• Highlight contributions from outside organizations and recognize them in reports or release notes.
• Use mailing lists for all decisions, avoiding private coordination channels that reinforce internal control.
• Mentors can help explain the value of vendor neutrality and why it’s essential for graduation.

...

Scenario

...

: Quiet Lists, Fading Energy

A once-active podling has gone quiet. Commits are infrequent, mailing-list traffic has dropped, and reports often arrive late. A few contributors say they’re busy with other projects, but no new participants are joining. Mentors worry the community may be losing momentum, but don’t want to overstep or discourage the team.

...

Podlings that succeed in incubation demonstrate consistent releases, diverse participation, healthy discussions, and self-correction when issues arise.
These scenarios show typical situations near the end of incubation, when projects test their independence and the community begins to think beyond mentors and oversight.

...

Scenario

...

: Ready… or Rushed?

A podling’s main sponsor suggests it should graduate quickly to improve its reputation and attract new users. Several PPMC members agree, saying, “We’ve had two releases, we’re done.” However, mentors notice that most votes and reports still depend on their prompting. When asked how the community plans to manage new committer elections or governance transitions, silence follows.

...

• Encourage the PPMC to perform a self-assessment using the Podling Maturity Model.
• Celebrate progress but discuss what independence looks like in practice, regular votes, self-managed releases, and community-led reports.
• Frame graduation not as a deadline, but as the natural result of demonstrated maturity.
• Mentors can share examples of successful graduations where the community already operated as a PMC before the vote.

...

Scenario

...

: Mentor Dependency

Even after more than a year in incubation, a podling still relies heavily on mentors to drive votes, file reports, and interpret ASF rules. Most contributors focus on coding; a few participate in governance tasks. When mentors pause for a few weeks, the project stalls. Mentors are concerned that their presence may be masking a lack of community confidence.

...

• Mentors can step back strategically, delaying responses to allow podling members to answer questions or call votes.
• Encourage rotation of report drafting and release management among PPMC members.
• Use mentoring moments to explain why a process exists, not just how to follow it.
• When the community can handle ASF processes without mentor intervention, graduation readiness is usually near.

...

Scenario

...

: The Graduation Vote

After months of preparation, a podling submits its graduation resolution to the Incubator PMC for vote. Most responses are +1, but one IPMC member objects, claiming “the community is still too small.” The podling feels frustrated. They’ve followed every step, have a working governance model, and just completed a successful release. Mentors wonder how to strike a balance between encouraging and respecting IPMC oversight.

...

These scenarios illustrate how podlings encounter real-world challenges in consistently applying those rules.

...

Scenario

...

: Branding Confusion

A podling announces a release on social media as “ 1.0 is out!” The tweet omits “Apache” and “(incubating).” Shortly after, a mentor reminds the community that this could mislead users into thinking the project is already a full Apache TLP. Some contributors argue it’s “just marketing.”

...

• Acknowledge the error publicly and repost using the correct form: “Apache Foo (incubating) 1.0 released.”
• Update social-media bios, README files, and websites to use consistent ASF branding.
• Remind the community that proper name use protects both the project and the ASF’s trademark integrity.
• Treat branding checks as part of the release verification and graduation readiness process.

...

Scenario

...

: Missing License Headers

During a release vote, an IPMC reviewer notices several new source files lack license headers. Developers respond that they used snippets from Stack Overflow and forgot to add the ASF header. The release manager is unsure whether this requires a new RC or just a fix in-place.

...

• Pause the release vote and create a new release candidate with corrected headers.
• Verify that all external code snippets are under compatible licenses and properly attributed.
• Use Apache RAT, add a simple “license-check” script or CI step to flag missing headers before tagging a release.
• Use the experience to strengthen awareness of ASF’s licensing and NOTICE requirements.

...

Scenario

...

: Handling Contributor Data

A podling launches a user survey to guide roadmap priorities. The form asks for names, email addresses, and company affiliations. A mentor asks whether this complies with ASF privacy policy. The team hadn’t considered that storing this data, even temporarily, creates obligations for consent and retention.

...

Successful projects maintain transparency, welcome new contributors, and adapt to change. They also recognize when help is needed, from the Board, Infra, or the wider ASF community, before small issues grow large. These scenarios illustrate what comes next after graduation: leadership transitions, maintaining diversity, and keeping communities resilient.

...

Scenario

...

: The Disappearing Mentor

A project has recently graduated and is proud of its new PMC. Several mentors who helped through incubation were invited to stay involved, but after graduation, they quietly stepped away. Soon, new committers join who have never interacted with any of the original mentors or learned from their context. The community worries about losing continuity and institutional memory.

...

• Before graduation, ensure that key processes (releases, voting, reporting) are documented in the project’s own wiki or site.
• Invite former mentors to share short “handover” notes summarizing what worked well during incubation.
• Maintain continuity by pairing experienced committers with newcomers for onboarding.
• Treat mentor withdrawal as healthy, a sign of independence, while ensuring knowledge remains accessible.

...

Scenario

...

: Chair Transition, Not Leadership Change

A long-time committer who served as the first PMC chair decides to step down due to personal commitments. While the PMC supports the decision, no one feels confident taking over.
Some members suggest asking the former chair to continue “just a bit longer.”

...

• Remind the community that the PMC, not the chair, governs the project. The chair simply reports Board status and maintains records.
• Encourage open nominations on the private@ list; any active PMC member can serve as chair.
• View chair rotation as routine administration, not a leadership crisis.
• Use this moment to refresh the PMC roster, documentation, and shared ownership of duties.
• The outgoing chair can assist with handover, but should allow the new chair to handle Board liaison responsibilities independently.

...

Scenario

...

: The Dormant TLP

A project that graduated a year ago has become nearly inactive. No releases are happening, mailing list traffic is low, and reports to the Board are sporadic. A few remaining committers still care deeply, but they aren’t sure how to re-engage the wider community. They worry that the Board may view the project as dormant.

...

Graduation is only one milestone. Healthy projects and healthy mentors foster ongoing learning, mentoring, and improvement long after the initial journey.

...

Scenario

...

: Lessons Not Shared

A podling successfully graduates after two years of incubation. The community is proud and quickly moves on to new releases. However, the mentors realize that no one has documented what worked, what didn’t, or what might help the next generation of podlings. Other incubating projects face similar challenges but have to rediscover the same lessons.

...

• Add a short retrospective to the final incubation report or graduation announcement.
• Contribute practical insights to the Incubator wiki, community blog, or ComDev resources.
• Encourage future mentors and PPMCs to read and update training materials with real examples.
• Remember that knowledge-sharing closes the loop, it turns personal experience into community improvement.

...

Scenario

...

: Mentor Growth

A long-time mentor realizes they’ve guided multiple podlings but haven’t revisited ASF policies or training in several years. New tools, procedures, and cultural expectations have evolved.
They worry that their advice might be outdated or inconsistent with current practice.

...

• Periodically review ASF training decks, updated Incubator policies, and board meeting summaries.
• Participate in mentor discussions on general@incubator.
• Pair with newer mentors to exchange perspectives, experience and fresh eyes complement each other.
• Treat mentoring as mutual learning: every podling teaches something new about The Apache Way.

...

Scenario

...

: Improving the Incubation Experience

After several graduation reviews, mentors notice similar patterns repeating: podlings struggle with release policy, reporting consistency, and community diversity. Rather than treating each case in isolation, a few mentors suggest updating shared documentation or training materials. However, no one is sure who maintains them or how to propose improvements.

...