...

• 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 they represent the full picture, including challenges.
• If a report omits serious issues, mentors can follow up on the mailing list and suggest a correction or clarification.
• Encourage the PPMC to discuss concerns openly before each report, so potential problems are recognized and documented early.
• Treat report preparation as a shared learning exercise, not a compliance task.

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

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 how or when 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 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.

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

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.

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

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

• What signals show that new contributors are being welcomed—or overlooked?
• How can the community ensure that contributions receive timely and public acknowledgment?
• 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, thank 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 inclusive tone, brief, welcoming replies on the mailing list, set 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 a genuine consensus never forms, the project still follows a single voice.

Reflection questions

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

Possible path forward

...

Scenario: Unrealistic Expectations of ASF Infrastructure

In one podling, contributors became frustrated when requests for mailing list setup and website publishing 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 that their timelines don’t derail 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 scoped 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.

...

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

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 how or when 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 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.

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

...

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.

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

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

• What signals show that new contributors are being welcomed—or overlooked?
• How can the community ensure that contributions receive timely and public acknowledgment?
• 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, thank 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 inclusive tone, brief, welcoming replies on the mailing list, set 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 a genuine consensus never forms, the project still follows a single voice.

Reflection questions

• Why can pre-existing leadership structures make it hard for a community to transition to ASF-style governance?
• How can mentors and the PPMC encourage shared ownership without alienating the project’s original leaders?
• 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 other contributors to participate in discussions and votes so that authority becomes more distributed.
• 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.
• Recognize that true graduation readiness means decisions can continue smoothly even if the founder steps back.

...

Scenario: Corporate Withdrawal and Loss of Momentum

In one podling, most development, reviews, and releases were done by employees of a single sponsor. When that sponsor changed priorities and reassigned staff, project activity quickly declined. Mailing list traffic slowed, releases stalled, and mentors raised concerns about 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 (reviews, releases, website updates).
• 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
• Acknowledge the founder’s experience and invite them to mentor others in shared decision-making.
• Encourage other contributors to participate in discussions and votes so that authority becomes more distributed.
• 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.
• Recognize that true graduation readiness means decisions can continue smoothly even if the founder steps back.

...

Podling Readiness and Graduation

...