...

A podling’s contributors agree in a GitHub issue to change the project’s API design. The discussion seems settled, everyone active on the repository has approved the change, and the pull request is merged. A week later, a mentor notices there was no corresponding discussion or record on the dev@ list. When the topic is raised, some participants argue that “it was already agreed on in GitHub comments.” Others had never seen the conversation and feel excluded. The mentor explains that ASF decisions must be made, and visible, on the project’s public mailing list, not only in tools or private channels.

Reflection questions

• Why does making decisions off-list create problems for transparency and inclusion?
• What makes the dev@ mailing list the canonical record of consensus at the ASF?
• How can mentors and PPMCs help teams strike a balance between efficiency and accountability?

Possible path forward

• Reopen the discussion on the dev@ list, summarizing what was agreed elsewhere and inviting confirmation or objections.
• Remind the community that “if it didn’t happen on the list, it didn’t happen” — mailing lists preserve institutional memory and visibility.
• Encourage a short practice: when a decision or major merge happens off-list, post a recap email to document it.
• Mentors can model this by regularly moving key discussions from chat, GitHub, or meetings back to the public list.
• Over time, this habit fosters trust, enhances onboarding for new contributors, and ensures that decisions remain discoverable years later.

...

Several active PPMC members work for the same company that initially proposed the podling. As the project matures, company goals begin to align with community priorities, such as marketing deadlines, roadmap direction, or product integration timelines. Decisions on the dev@ list often mirror internal discussions, and other contributors hesitate to question them. When a mentor raises this concern, the PPMC insists that “everyone agrees internally,” but little discussion happens in public.

Reflection questions

• How can PPMC members recognize when company interests are influencing project decisions?
• What safeguards ensure that ASF projects remain independent of corporate agendas?
• What role should mentors and the IPMC play in helping a community maintain neutral, consensus-based governance?

Possible path forward

• Encourage all technical and strategic discussions to take place publicly on the mailing list, regardless of any prior internal agreements.
• When posting on behalf of an employer, clarify whose view you represent and invite others to comment openly.
• Rotate release managers, vote initiators, and report drafters to ensure shared ownership beyond a single organization.
• Mentors can remind the community that ASF projects operate by public consensus, not by company alignment—corporate support is welcome, but direction comes from the community.
• If necessary, the PPMC or IPMC can invite new contributors from outside the company to broaden participation and strengthen neutrality.

...

During several community discussions, a mentor and two PPMC members consistently argue for a particular technical direction. Later, it is discovered that all three work for the same company, which plans to integrate the feature into its product. Their affiliation wasn’t hidden, but it was never clearly stated in the relevant threads or votes. New contributors assumed the support was broad and independent. When this is raised, the individuals insist they were “just speaking as community members.” The incident damages trust and prompts a wider discussion about disclosure and transparency.

Reflection questions

• Why is it important to disclose company or organizational affiliations in ASF communities?
• How can mentors model transparent communication when their employer also has a stake in the project?
• What happens when affiliations aren’t clear and influence perceptions of consensus or neutrality?

Possible path forward

• Encourage contributors to disclose their affiliations when relevant, especially in discussions where corporate interests may overlap with community decisions.
• Remind everyone that consensus depends on clarity. The ASF expects decisions to be community-driven, not company-directed.
• If confusion arises, clarify on-list to restore trust and reaffirm that votes and discussions represent individual opinions, not those of employers.
• Use moments like this to reinforce vendor neutrality as part of the ASF’s governance culture.

...

A podling submits its quarterly report, describing the community as “active and healthy,” which highlights several releases and broad participation. Mentors and IPMC members, however, are aware that mailing list traffic has decreased, and contributor engagement has been inconsistent. When asked, the PPMC explains that they “didn’t want to sound negative” in a public report. Mentors remind the community that reports are not public relations statements, they are a core part of the ASF’s oversight and learning process.

Reflection questions

• Why must podling reports reflect reality, not just optimism?
• What responsibilities do mentors and the PPMC share for ensuring accurate reporting?
• How can mentors help communities be open about problems without fear of criticism?

Possible path forward

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

...

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.

...

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.

...

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 seems a company involved in the project is misusing their brand. The podling feels frustrated, why are these issues surfacing only now? Mentors realize that although the podling had matured, a few key steps were assumed rather than verified.

Reflection questions

• Why do unexpected issues sometimes appear during graduation votes?
• How can mentors and PPMCs anticipate and address these before the resolution is submitted?
• What does this reveal about shared responsibility between mentors, the IPMC, and the podling community?

Possible path forward

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

...

• Review the ASF Privacy Principles and remove or anonymize any stored personal data.
• If feedback is needed, redesign the survey to avoid collecting identifiable information (or make responses 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.

...

Scenario: Brand and Governance Blur

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 podling’s primary corporate sponsor publishes a press release and social media posts describing the project as “an open source initiative by Company X”, using graphics that closely resemble the ASF logo. The announcement omits the “Apache (incubating)” name. When mentors raise the issue, company representatives respond that this approach is “perfectly fine” because it promotes both the company and the project. The mentors are concerned that this blurs the project’s independence and confuses the project’s relationship with the ASF.

Reflection questions

• Why does ASF branding and naming accuracy matter for project independence and public trust?
• How can mentors and PPMC members respond when a company’s promotion blurs project governance or identity?
• 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 the full project name: Apache (incubating).
• Engage with the company privately and explain why 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.

...

Scenario: Release Hygiene in Practice

During a release vote, an IPMC member notices several issues in the release candidate: unsigned artifacts and missing DISCLAIMER and NOTICE files. The release manager explains that these steps were skipped “to save time” and that the podling will fix them next time. Mentors step in to explain that these are not optional details—they are part of ASF’s legal and quality framework.

Reflection questions

• Why is release hygiene essential to ASF credibility and trust?
• How can mentors help the community treat release preparation as a shared responsibility rather than a single person’s task?
• What practical tools or checklists can help prevent these issues in future releases?

Possible path forward

• Pause the vote and work with the community to correct the issues, creating a new release candidate that meets ASF standards.
• Add a simple release checklist to the project’s wiki or repository, covering signatures, licenses, disclaimers, and vote announcements.
• Encourage multiple people to participate in release preparation so knowledge and responsibility are shared.
• Incorporate release verification tools such as Apache RAT and automated license checks into the project’s build process.
• Treat every release vote as both a quality review and a learning opportunity for the whole community.

...

Post-Graduation and Long-Term Sustainability

...