...

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

...

Podling Readiness and Graduation

Graduation marks the point when 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.

...