Page History

...

• 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

...

17: 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

...

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

...

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

...

19: 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

...

20: 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

...

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

...

Graduation is only one milestone. Healthy projects and healthy mentors foster ongoing learning, mentoring, and improvement long after the initial journey.

...

Scenario

...

22: 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

...

23: 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

...

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

...