Page History

...

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

...

1. How can a podling plan Infra requests so that their timelines don’t derail 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?

...

In one podling proposal, mentors were added late in the process. Some were chosen added because they were well-known ASF Members or from 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.

...

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 their reputation or affiliationa 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.

...

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 prodling podling did not report them, the . 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.

...

• 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 . Timely communication helps protect both the podling and the wider community.

...

Scenario: Conflicting Mentor Advice

In one podling, mentors gave different 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 instructionsguidance?
3. How can the IPMC help maintain a shared understanding of policies and mentor responsibilities?

...

Scenario: The Heated Thread

A technical debate about over the project’s build system becomes turns personal. Two contributors begin trading sharp remarks on the mailing list, each insisting their approach is correct. Other participants go silent, unsure uncertain how to intervenerespond. 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 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.

...

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

...

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

...

Scenario: The Single-Maintainer Risk

A podling’s activity appears strong, with regular commits, quick pull-request merges, and responsive issue triage; however. 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‘community over code’. Long-term health depends on shared responsibility, not individual productivity, 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 started begun to withdraw, saying they don’t feel their input is valued or that decisions are already 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?

...

Scenario: Quiet Lists, Fading Energy

A once-active podling has gone 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.

...

• Create a simple new contributor checklist: respond on-list to first-time posts, thank contributors 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, and set 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 a 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?

...

• Acknowledge the founder’s experience and invite them to mentor others in shared decision-making.
• Encourage other contributors others to lead discussions and participate in discussions and votes so that authority becomes is more distributedevenly 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.
• 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 handled by employees of a single sponsorsponsoring 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 of the project.

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.

...

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.

...

• 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 opportunities to explain why a process existsASF processes exist, not just how to follow itthem.
• When the community can handle ASF processes without mentor intervention, graduation readiness is usually near.

...

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@ general incubator list, asking for concrete 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.

...

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. Why are , wondering why these issues are surfacing only now? Mentors . Mentors realize that although the podling had matured, a few key steps were assumed rather than verified.

...

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

...

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

...

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

...

• Pause the release vote and create a new release candidate with corrected headers.
• Verify that all any external code snippets are under compatible licenses and properly 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.

...

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 even temporary storage of this data , even temporarily, 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 responses 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.

...

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 that uses using the full project name: Apache Foo (incubating).
• Engage with the company privately and to explain why 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.

...

A project has recently graduated and is proud of its new PMC. Several mentors who had helped guided the podling during the incubation period were invited to stay involved, but after graduation, they quietly stepped away after graduation. Soon 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.

...

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

...

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

...

Scenario: The Dormant TLP

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

...

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

...

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 might could help the next generation of podlings. Other incubating projects face similar challenges but have to rediscover the same lessons.

...

• 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 , experienceand experiences, and fresh eyes and seasoned insight complement each other.
• Treat mentoring as mutual learning: every podling teaches something new about The Apache Way.

...