...

The Apache Way is not a rulebook. Each discussion, vote, and release is an opportunity to apply those values, build trust through contribution, and help a project grow into a sustainable 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, consensus grows through conversation.
• Connect the dots: Link what you learn here with related materials: ASF Values, Governance in Practice, Mentor Training, 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 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 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.

...

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 1: 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 2: 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 3: 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.

...

• 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.
• Update the podling’s release checklist or wiki page with explicit steps and templates for cross-list voting.
• Mentors should confirm that both votes have concluded before declaring the release official.

...

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.

...

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

...

Scenario 4: 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 5: 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 6: 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.

...

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

...

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 7: 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 8: 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 9: 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.

...

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

...

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

...

Scenario 10: 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 11: 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 12: 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.

...

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

...

Podling Readiness and Graduation

Graduation marks the point when a podling has learned to govern itself 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 13: 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 14: 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 15: 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.

...

• Discuss the concerns openly on the general@ list, asking for concrete 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.

...

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.

...

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

...

Scenario 16: 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 (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 20: 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 21: 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.

...

A project that handles branding, legal, and privacy matters well shows more than procedural compliance — it shows maturity, transparency, and respect for trust.
These are the same qualities that define a successful Apache community.

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 22: 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 23: 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 24: 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.

...

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

...

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 25: 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 25: 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 26: 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.

...

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

...