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.  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 learn to apply these principles in everyday practice. Mentors guide communities as they move from informal decisions to open discussion, from individual effort to shared ownership, and ultimately toward the self-governance 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 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 seek practical guidance rooted in ASF norms.

What this is not: A policy manual. Official ASF policies are 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.

How to Use This Guide

This guide serves as a practical companion for anyone involved in the Apache Incubator, including mentors, PPMC members, podling contributors, and future PMC members. It combines concise explanations, real-world examples, and reflection exercises to demonstrate how ASF values become everyday community practices.

You can read it from start to finish or use it as a reference when specific issues arise. Each section focuses on a core theme (decision-making, mentoring, community health, conflict resolution, branding and privacy) and includes scenarios based on actual Incubator experience.

To get the most from this guide

• 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: Governance in Practice, Voting & Consensus in Practice, 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.

About Anonymity

All examples and scenarios in this guide are anonymized composites drawn from public ASF mailing list discussions. 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, 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.

In the Incubator, podlings often learn these lessons through practice. Common challenges include unclear vote scope, misuse of lazy consensus, or missed cross-list communication between the podling and the Incubator PMC (IPMC).

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:

"If there are no objections within 72 hours, 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?

Possible path forward

• 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 posting brief summary messages that confirm the outcome of lazy consensus discussions.

Scenario: Ambiguous Vote Scope

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

"[VOTE] Approve architecture changes 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.

Reflection questions

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 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 their 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’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?

Possible path forward

• Retract the published release and announce the correction openly, explaining that the IPMC vote was missed.
• 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 discussed and agreed in a GitHub issue to change the project’s API design. The discussion appears to be settled, as everyone active on the repository has approved the change, and the pull request 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 reminds the community that ASF decisions need to be discussed and visible on the project’s public mailing list, not only in tools or private channels.

Reflection questions

1. Why does making decisions off-list create problems for transparency and inclusion?
2. What makes the dev@ mailing list the canonical record of consensus at the ASF?
3. How can mentors and PPMCs help teams strike a balance between efficiency and accountability?

Possible path forward

• Reopen the discussion on the dev@ list, summarizing what was agreed elsewhere and inviting confirmation or objections.
• Remind the community that “if it didn’t happen on the list, it didn’t happen”, mailing lists preserve institutional memory and visibility.
• Encourage a short practice: when a decision or major merge happens off-list, post a recap email to document it.
• Mentors can model this by regularly moving key discussions from chat, GitHub, or meetings back to the public list.

Mentoring and Oversight

Mentors are the bridge between a podling and the Apache Software Foundation. Their role is not to direct the project, but to guide it toward self-governance, ensuring the community learns to make decisions transparently, respect ASF policy, and maintain healthy dynamics.

Practical mentorship balances advice and autonomy. When mentors step in too heavily, the community may become dependent. When mentors disengage, important issues can go unnoticed until they grow into real problems.

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 regular commits, discussions, and releases. However, one of its listed mentors hasn’t posted to the mailing list for 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.

Reflection questions

1. What should the remaining mentors and PPMC do in this situation?
2. How might mentor inactivity affect podling oversight and readiness for graduation?
3. What steps can the IPMC take to ensure mentorship coverage stays healthy?

Possible path forward

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

Reflection questions

1. How can the mentor recognize that their helpfulness might be limiting community growth?
2. What signs indicate that a podling is overly reliant on a single mentor or contributor?
3. How can the PPMC rebalance participation and decision-making?

Possible path forward

• 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 the ASF policy was followed, but the tone created confusion about authority.

Reflection questions

1. What distinguishes a mentor’s advisory role from a PPMC’s decision-making responsibility?
2. How can mentors provide guidance without appearing to overrule the community?
3. How should the PPMC respond when mentor instructions seem to conflict with self-governance?

Possible path forward

• Clarify on the mailing list that mentors provide advice, not final approval, and that decisions belong to the PPMC.
• Encourage mentors to frame their guidance as “recommendations” or “ASF expectations,” rather than directives.
• Use moments like this as learning opportunities, reaffirming that mentoring supports independence, not control.

Scenario: The Conflicted PPMC

Several active PPMC members work for the same company that initially proposed the podling. As the project matures, company goals start to 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.

Reflection questions

1. How can PPMC members recognize when company interests are influencing project decisions?
2. What safeguards ensure that ASF projects remain independent of corporate agendas?
3. What role should mentors and the IPMC play in helping a community maintain neutral, consensus-based governance?

Possible path forward

• 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 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.

Scenario: The Unreliable Narrator

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 concealed but 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.

Reflection questions

1. Why is it important to disclose company or organizational affiliations in ASF communities?
2. How can mentors model transparent communication when their employer also has a stake in the project?
3. What happens when affiliations aren’t clear and influence perceptions of consensus or neutrality?

Possible path forward

• Encourage contributors to disclose relevant affiliations in threads where corporate interests may overlap, as this supports the perception of neutrality.
• Remind everyone that consensus depends on clarity. The ASF expects decisions to be community-driven, not company-directed.
• If confusion arises, clarify on-list to restore trust and reaffirm that votes and discussions represent individual opinions, not those of employers.
• Use moments like this to reinforce vendor neutrality as part of the ASF’s governance culture.

Scenario: The Glossed-Over Report

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?

Possible path forward

• Reiterate that reports are for transparency, not promotion, and accurate information allows the IPMC to provide timely help.
• Mentors should review draft reports and confirm that they represent the entire picture, including any challenges.
• If a report omits serious issues, mentors can follow up on the mailing list and suggest corrections or clarifications.
• Encourage the PPMC to discuss concerns openly before each report, so potential problems are recognized and documented early.
• Reports should accurately reflect reality, including any problems, and should not be generated by AI.

Scenario: Unrealistic Expectations of ASF Infrastructure

In one podling, contributors became frustrated when requests to set up mailing lists and 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.

Reflection questions

1. How can a podling plan Infra requests so their timelines don’t delay progress?
2. What’s the right way to communicate status and unblock work without creating policy or branding problems?
3. How can mentors model respectful collaboration with Infrastructure while keeping the podling moving?

Possible path forward

• File Infra tickets early and track them transparently.
• Post brief status summaries to the dev@ list so everyone understands sequencing and lead times.
• Avoid external “workarounds”; if truly necessary, discuss impacts with mentors first.

Scenario: Mentors Added for the Wrong Reasons

In one podling proposal, mentors were added late in the process. Some were added because they were well-known ASF Members or worked for the same company as the proposers, rather than because they had the time or interest to mentor. Once the project entered incubation, those mentors were largely inactive, leaving the podling without needed guidance on releases, community building, and ASF processes.

Reflection questions

1. What criteria should be used when selecting mentors for a new proposal?
2. How can the IPMC ensure mentors understand and commit to their responsibilities before a vote?
3. What should podlings do if a mentor is unresponsive or lacks relevant experience?

Possible path forward

• Choose mentors based on their engagement, availability, and complementary experience, viewing mentorship as an active commitment rather than a title.
• Encourage proposers to work with potential mentors early, before the proposal vote, to confirm mutual understanding.
• If a mentor is inactive, the podling should raise the issue on the incubator list and request a replacement through the normal process.

Scenario: Delayed Mentor Escalation

In one podling, mentors noticed that activity had slowed, releases were overdue, and a few individuals dominated discussions. Although these issues persisted for several quarters, the podling did not report them. The mentors hesitated to raise them with the Incubator PMC, hoping the community would recover on its own. When the podling later proposed graduation, the IPMC was surprised to learn about the extent of the problems, and the vote was postponed pending corrective action.

Reflection questions

1. When should mentors escalate persistent issues to the IPMC, and what kinds of problems warrant early discussion?
2. How can mentors balance supporting the podling privately with keeping the wider Incubator community informed?
3. What mechanisms exist to help mentors share concerns without damaging community trust?

Possible path forward

• Mentors should inform the IPMC promptly when a podling exhibits sustained inactivity, release delays, or governance issues.
• Use private@incubator for sensitive concerns and general@incubator for public awareness and guidance.
• Encourage the PPMC to document challenges transparently in reports so the IPMC can assist before issues become critical.
• Treat escalation as part of responsible mentorship, not as failure. Timely communication helps protect both the podling and the wider community.

Scenario: Conflicting Mentor Advice

In one podling, mentors offered conflicting guidance on key incubation steps. One mentor told the community to proceed with a release candidate, while another advised waiting for additional license review. The podling, unsure which direction to follow, paused work and sought clarification on the incubator mailing list. The inconsistent advice created confusion and slowed progress until the mentors and the IPMC clarified expectations together.

Reflection questions

1. How can mentors coordinate to ensure their guidance is consistent and aligned with ASF policy?
2. What should a podling do when mentors provide conflicting or unclear guidance?
3. How can the IPMC help maintain a shared understanding of policies and mentor responsibilities?

Possible path forward

• Mentors should communicate regularly with each other and with the IPMC to stay aligned on ASF practices.
• When uncertain, mentors should confirm their interpretation on the incubator list before advising the podling.
• Podlings should feel free to ask for clarification on general@incubator when advice appears inconsistent.
• Consistent, transparent communication between mentors prevents confusion and helps the podling learn The Apache Way more effectively.

Conflict Resolution and Communication

Disagreement can be a normal and healthy part of collaborative work. At the Apache Software Foundation, conflict can occur, but it must be handled openly, respectfully, and on the public mailing list. The goal is not to avoid tension, but to turn it into constructive dialogue that strengthens trust and understanding.

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 over the project’s build system turns personal. Two contributors begin trading sharp remarks on the mailing list, each insisting their approach is correct. Other participants go silent, uncertain how to respond. After several days, the discussion ends abruptly, but one contributor stops participating altogether.

Reflection questions

1. How should community members respond when a discussion starts to become personal or hostile?
2. What can mentors or PPMC members do to de-escalate a heated thread without taking sides?
3. How can the project repair trust after conflict?

Possible path forward

• 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 when or how these decisions were made. When a mentor raises the issue, the group says, “We were just being efficient.”

Reflection questions

1. Why does making decisions in private channels undermine ASF transparency?
2. How can mentors help the community move private discussions back to public spaces?
3. What habits or tools can reinforce open communication?

Possible path forward

• 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 while reinforcing the long-term value of public archives for learning and accountability.

Scenario: Cultural Misunderstanding

A contributor from one region tends to write brief, direct comments that 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.

Reflection questions

1. How can cultural norms around communication lead to misunderstanding in a global community?
2. What can mentors and PPMCs do to surface and address these issues early?
3. How can the project accommodate diverse communication styles while maintaining respect?

Possible path forward

• Raise the issue gently on the mailing list or in a private note, framing it as a shared learning opportunity rather than a personal fault.
• Encourage contributors to assume good faith and ask clarifying questions when tone seems unclear.
• Add a short “communication norms” section to the podling’s wiki or README, reflecting the team’s diversity and shared expectations for tone and communication.
• Mentors can model inclusive phrasing and remind everyone that written tone varies across cultures.

Community Health and Growth

A healthy Apache community is diverse, transparent, and resilient. It welcomes new contributors, balances technical and non-technical participation, and ensures no single person or company dominates. Healthy communities communicate openly, share responsibility, and support contributors as they grow into committers and leaders.

In the Incubator, community health is the clearest signal of readiness for graduation. Podlings that release content regularly, maintain active discussions, and demonstrate independent governance are typically the ones that thrive after graduation.

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.

Reflection questions

1. What risks does heavy reliance on one person create for a podling’s sustainability?
2. How can mentors and the PPMC encourage broader participation and shared ownership?
3. What signals should the IPMC look for before graduation?

Possible path forward

• 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.
• Identify areas where others can contribute, such as documentation, testing, website updates, or triage, and encourage participation in those areas to lower barriers to entry.

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 begun to withdraw, saying they don’t feel their input is valued or that decisions are being made internally.

Reflection questions

1. How can a podling strike a balance between valuable corporate support and the need for independent community governance?
2. What signs show that a project’s culture is vendor-dominated rather than community-driven?
3. How can mentors help the PPMC create more neutral ground for decision-making?

Possible path forward

• 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 grown 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.

Reflection questions

1. What early indicators suggest a community’s energy is fading?
2. How can mentors and PPMCs re-ignite participation without taking over?
3. When does it make sense to seek help from the IPMC or the wider ASF community?
4. How should mentors handle situations where revitalization attempts don’t succeed?

Possible path forward

• Start a discussion on the dev@ list about the podling’s goals, roadmap, and any blockers to progress.
• Revisit public plans or documentation to identify tasks that could attract new contributors.
• Celebrate small wins, merged PRs, documentation updates, or test improvements, to rebuild momentum.
• If sustained participation cannot be regained after a sincere effort, mentors should initiate an open discussion about retirement on the mailing list.
• Treat retirement as a neutral outcome, not a failure: it preserves transparency, honors past work, and leaves the door open for future revival.

Scenario: The Overlooked Contributor

A new contributor submits several thoughtful pull requests and posts introductions on the dev@ list, but receives little or no response. A few weeks later, they stop engaging. When mentors review project activity, they notice several first-time contributors who never returned. The community has been busy with releases and technical work, but no one has been ensuring newcomers are acknowledged or guided toward deeper involvement.

Reflection questions

1. What signals show that new contributors are being welcomed or overlooked?
2. How can the community ensure that contributions receive timely and public acknowledgment?
3. What small steps can mentors or committers take to lower the barrier from “first PR” to “regular contributor”?

Possible path forward

• Create a simple new contributor checklist: respond on-list to first-time posts, acknowledge contributors by name, and link them to starter issues.
• Rotate “review buddy” duties so experienced committers respond quickly to new PRs.
• Include first-time contributors in release or report summaries to recognize their efforts publicly.
• Encourage mentors to model an inclusive tone and brief, welcoming replies on the mailing list, setting stronger norms than formal rules.

Scenario: The Reluctant Leader

A podling enters incubation with an established codebase and a long-time maintainer who founded the project. The community appreciates their expertise and historical knowledge, but over time, most key decisions still depend on this individual’s approval. When others raise ideas or concerns, they often defer, saying, “Let’s wait for the founder’s input.” Mailing list discussions stall until that person responds. Mentors notice that votes are unanimous, but only after the founder states their opinion first. The pattern appears cooperative, but genuine consensus never forms, the project still follows a single voice.

Reflection questions

1. Why can pre-existing leadership structures make it hard for a community to transition to ASF-style governance?
2. How can mentors and the PPMC encourage shared ownership without alienating the project’s original leaders?
3. What signals show that decision-making is still centered on an individual rather than the community?

Possible path forward

• Acknowledge the founder’s experience and invite them to mentor others in shared decision-making.
• Encourage others to lead discussions and participate in votes so that authority is more evenly shared.
• Mentors can model consensus-building by asking open questions instead of deferring to one person’s view.
• If patterns persist, mentors and the PPMC should document them in reports and discuss ways to promote independence.

Scenario: Corporate Withdrawal and Loss of Momentum

In one podling, most development, reviews, and releases were handled by employees of a single sponsoring company. When that sponsor changed priorities and reassigned staff, project activity quickly declined. Mailing list traffic slowed, releases stalled, and mentors raised concerns about the project's sustainability.

Reflection questions

1. What signals indicate that a podling’s activity depends too heavily on one employer?
2. How can a podling spread knowledge of releases, infrastructure, and governance across multiple contributors?
3. What should mentors encourage before, during, and after a sponsor steps back?

Possible path forward

• Identify single-person or single-employer bottlenecks and rotate responsibilities such as reviews, releases, and website updates to spread knowledge and reduce risk.
• Invite frequent contributors to take on discrete tasks and document processes openly so new people can step in.
• Acknowledge the change in quarterly reports, outline mitigation steps, and track whether participation diversifies over time.

Podling Readiness and Graduation

Graduation marks the point at which a podling has learned to govern itself in the Apache Way. It is not a reward or certification, but recognition that the community already behaves like an Apache Project Management Committee (PMC). By graduation, mentors should be nearly invisible, guiding only when needed, while the podling makes transparent, independent decisions.

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.

Reflection questions

1. What signs show that a podling is genuinely ready to graduate?
2. Why can rushing graduation harm both the project and the Foundation?
3. How can mentors guide a conversation about readiness without discouraging enthusiasm?

Possible path forward

• Encourage the PPMC to perform a self-assessment using the Podling Maturity Model to evaluate readiness against ASF criteria.
• 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.

Reflection questions

1. How can mentors tell when their guidance has become dependency?
2. What steps can a podling take to build governance confidence among its own members?
3. How can the community gradually assume more responsibility before graduation?

Possible path forward

• 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 opportunities to explain why ASF processes exist, not just how to follow them.
• 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 a 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.

Reflection questions

1. What is the IPMC’s role in graduation decisions, and how can mentors assist the podling in navigating this process?
2. How can the community respond constructively to objections?
3. What can be learned from a delayed or re-voted graduation?

Possible path forward

• Discuss the concerns openly on the general incubator list, asking for specific reasons and suggestions for improvement.
• Treat the feedback as part of the learning process, not as rejection.
• Update the graduation resolution or reports to address any gaps, then resubmit when ready.
• Mentors can remind the community that graduation is confirmed by consensus, and sometimes consensus takes more than one vote.

Scenario: The Graduation Surprise

A podling submits its graduation resolution after months of preparation and receives mostly positive feedback. Then, during the vote, an IPMC member raises a concern that catches the community off guard: it appears that a company involved in the project is misusing its brand. The podling feels frustrated, wondering why these issues are surfacing only now. Mentors realize that although the podling had matured, a few key steps were assumed rather than verified.

Reflection questions

1. Why do unexpected issues sometimes appear during graduation votes?
2. How can mentors and PPMCs anticipate and address these before the resolution is submitted?
3. What does this reveal about shared responsibility between mentors, the IPMC, and the podling community?

Possible path forward

• Treat surprises as learning opportunities rather than failures. Graduation readiness is about transparency, not perfection.
• Before submitting a resolution, review past reports, mentor sign-offs, and branding and license audits together as a final checklist.
• Encourage mentors to raise potential concerns early and publicly, not only during votes.
• If a new issue surfaces, pause the vote, address it collaboratively, and resubmit once consensus is rebuilt.
• Document lessons learned in the final graduation report to help future podlings avoid the same surprise.

Branding, Legal, and Privacy in Practice

Every Apache project represents the Foundation publicly, through its name, website, releases, and community interactions. Respecting ASF branding, legal, and privacy policies is essential for maintaining trust with contributors, users, and the broader open-source ecosystem.

During incubation, mentors help projects understand these areas in practice:

• Branding: using the “Apache Foo (incubating)” name correctly, following logo and trademark policies.
• Legal: ensuring all code has clear provenance, appropriate licenses, and accurate NOTICE and DISCLAIMER files.
• Privacy: handling contributor and user data responsibly, in line with ASF’s privacy principles.

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.”

Reflection questions

1. Why does accurate naming matter for ASF and for the project’s credibility?
2. How should the community address public posts or materials that fail to include required branding?
3. How can projects balance enthusiasm with responsibility when promoting their work?

Possible path forward

• 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 consistent and accurate naming protects both the project’s credibility 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.

Reflection questions

1. Why must every source file have a clear license header and provenance?
2. What risks arise from using third-party code without confirming its license?
3. How can the podling build habits to prevent this issue in future releases?

Possible path forward

• Pause the release vote and create a new release candidate with corrected headers.
• Verify that any external code snippets are under compatible licenses and correctly attributed.
• Use Apache RAT and 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 even temporary storage of this data creates obligations for consent and retention.

Reflection questions

1. What personal data does the ASF consider sensitive, and why must it be handled carefully?
2. How can projects collect feedback responsibly while respecting ASF privacy expectations?
3. What should a podling do if it has already collected data without a clear consent statement?

Possible path forward

• Review the ASF Privacy Principles and remove or anonymize any stored personal data, collecting only what’s essential in future surveys.
• If feedback is needed, redesign the survey to avoid collecting identifiable information, or make personal fields optional
• Add a short privacy notice explaining how data will be used and for how long it will be retained.
• Share lessons learned on the dev@ list so everyone understands the ASF’s privacy culture.

Scenario: Brand and Governance Blur

A podling’s primary corporate sponsor publishes a press release and social media posts describing the project as “an open source initiative by Company X”, using graphics that closely resemble the ASF logo. The announcement omits the “Apache (incubating)” name. When mentors raise the issue, company representatives respond that this approach is “perfectly fine” because it promotes both the company and the project. The mentors are concerned that this blurs the project’s independence and confuses the project’s relationship with the ASF.

Reflection questions

1. Why does ASF branding and naming accuracy matter for project independence and public trust?
2. How can mentors and PPMC members respond when a company’s promotion blurs project governance or identity?
3. What practices help maintain a clear boundary between corporate marketing and ASF community communication?

Possible path forward

• Acknowledge the issue publicly and post a corrected statement using the full project name: Apache Foo (incubating).
• Engage with the company privately to explain that accurate ASF branding and neutral representation are essential for community credibility.
• Review the project’s website, social media, and README to ensure consistent ASF-compliant naming and disclaimers.
• Encourage mentors to reinforce that the ASF owns all Apache brands and that corporate promotion should highlight participation, not control.

Scenario: Release Hygiene in Practice

During a release vote, an IPMC member notices several issues in the release candidate: unsigned artifacts and missing DISCLAIMER and NOTICE files. The release manager explains that these steps were skipped “to save time” and that the podling will fix them next time. Mentors step in to explain that these are not optional details, they are part of ASF’s legal and quality framework.

Reflection questions

1. Why is release hygiene essential to ASF credibility and trust?
2. How can mentors help the community treat release preparation as a shared responsibility rather than a single person’s task?
3. What practical tools or checklists can help prevent these issues in future releases?

Possible path forward

• Pause the vote and work with the community to correct the issues, creating a new release candidate that meets ASF standards.
• Add a simple release checklist to the project’s wiki or repository, covering signatures, licenses, disclaimers, and vote announcements.
• Encourage multiple people to participate in release preparation so knowledge and responsibility are shared.
• Incorporate release verification tools such as Apache RAT and automated license checks into the project’s build process.

Post-Graduation and Long-Term Sustainability

Graduation is not the end of the journey; it’s the beginning of self-governance. Once a podling becomes a top-level project, it must manage its own community health, releases, and decision-making without the safety net of mentors or the Incubator PMC. The habits formed during incubation determine how sustainable the project will be in the years ahead.

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 had guided the podling during incubation were invited to stay involved, but quietly stepped away after graduation. 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.

Reflection questions

1. How can a newly graduated project retain knowledge and cultural continuity after mentors step back?
2. What documentation or onboarding practices help preserve lessons from incubation?
3. How can former mentors continue supporting the project without overshadowing it?

Possible path forward

• 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 a healthy sign of independence, while ensuring that 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 for ‘just a bit longer.’

The ASF Board liaison reminds them that the chair’s role is administrative, not one of authority, and that continuity depends on the PMC as a whole.

Reflection questions

1. Why is the PMC chair’s role different from traditional leadership positions?
2. How can a PMC avoid over-identifying project direction or stability with a single individual?
3. What practical steps ensure smooth administrative transitions?

Possible path forward

• 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 assume Board liaison responsibilities independently.

Scenario: The Dormant TLP

A project that graduated a year ago has grown 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.

Reflection questions

1. What steps can a project take to revive activity after a long, quiet period?
2. When should a PMC consider seeking assistance from the Community Development or Brand Management teams?
3. How should the community approach retirement as a top-level project?

Possible path forward

• Start a public thread inviting discussion on the project’s direction, goals, or maintenance plan.
• Revisit the user base, mailing lists, GitHub issues, or social channels to identify new contributors or adopters.
• If energy remains low, the PMC can explore options such as joining forces with another ASF project or retiring gracefully.
• Treat dormancy discussions as part of responsible stewardship: transparency and honesty are core to long-term sustainability.

Graceful Retirement

After a period of reduced activity, a podling’s mailing lists have gone mostly quiet, and no recent releases have been made. Mentors reach out and find that most contributors have shifted focus to other projects or work responsibilities. The remaining community members still care about the project but aren’t sure how to regain momentum. The mentors suggest discussing retirement openly to decide the project’s future together.

Reflection questions

1. How can mentors and PPMC members tell when a podling’s decline is temporary or long-term?
2. What steps help a community make a transparent, respectful decision about retirement?
3. How can projects preserve knowledge and history so that their work remains useful after the retirement of their creators?

Possible path forward

• Start an open discussion on the dev@ list about the podling’s status, goals, and possible next steps.
• If consensus forms around retirement, post the discussion summary and proposal to general@incubator for IPMC review and vote.
• Archive documentation, releases, and discussions so that future contributors can easily rediscover and reuse the work.
• Frame retirement as a responsible conclusion, not a failure, it protects the ASF’s integrity and honors the volunteers’ efforts.
• If interest resurfaces later, a new proposal can always revive the project with a refreshed community.

Reflection and Continuous Learning

The Apache Way is not a fixed rulebook. It’s a culture of learning, adaptation, and trust. Each project interprets these values through its own community, challenges, and evolution. Incubation teaches processes and policies, but more importantly, it teaches how to reflect, adapt, and share what you’ve learned so that others can benefit.

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 well, what didn’t, or what could help the next generation of podlings. Other incubating projects face similar challenges but have to rediscover the same lessons.

Reflection questions

1. Why is sharing lessons learned an important part of ASF culture?
2. How can projects capture experiences without creating extra bureaucracy?
3. What channels exist for sharing reflections within the ASF?

Possible path forward

• 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.

Reflection questions

1. How can mentors maintain currency with ASF policy and community norms?
2. Why is self-reflection part of good mentorship?
3. What opportunities exist for mentors to keep learning?

Possible path forward

• 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 and experiences, fresh eyes and seasoned insight 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.

Reflection questions

1. How can mentors and IPMC members contribute back to improving the Incubator itself?
2. What channels exist for sharing observations or updating guidance?
3. Why is continuous improvement part of sustaining a healthy mentoring culture?

Possible path forward

• Raise suggestions or improvement threads on general@incubator.apache.org so the community can discuss and reach consensus.
• Contribute edits directly to the Incubator wiki or Training site via pull requests or edit requests.
• Share anonymized examples (like those in this guide) to help refine future training.
• Remember: incubation is a two-way learning process. Each podling’s experience should make the next one’s journey smoother.

Keep the Cycle Going

Every ASF member, committer, and mentor contributes to a living ecosystem. By reflecting on successes, documenting challenges, and helping others learn faster, you strengthen not just one project, but the entire Foundation. The Apache Way endures because it continues to grow alongside its people.