Page History

...

The examples and scenarios are anonymized composites drawn from real ASF experiences. They illustrate what works, what doesn’t, and how communities learn by doing—from doing, from unclear votes to mentor disengagement to cultural misunderstandings.

...

What this is not. A policy manual. Authoritative policies live are available on ASF sites; this focuses , focusing on how to apply them in everyday project work.

...

• 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: ASF Values, Governance in Practice, Mentor Training, 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.

...

• The mentor should encourage the community to pause and revisit the discussion before treating the vote as final.
• Remind the podling that consensus comes first, votes are used to confirm shared understanding, not to decide by majority.
• For future threads, use clear subject tags and intent markers:
  • [DISCUSS] for exploration and consensus building
  • [VOTE] once agreement has been reached and the community is ready to record it
  • [RESULT] to summarize the outcome and next steps
• Mentors can guide Encourage the PPMC toward documenting their own conventions for to document when and how formal votes are used, reinforcing open discussion as the default; discussion first, vote second.

...

Scenario: Cross-List Release Vote Confusion

...

• Retract the published release and announce the correction openly, explaining that the IPMC vote was missed.
• Restart the vote following the proper procedure: first on the podling’s dev@ list, then on the general@incubator list once the first vote passes.
• Restart the vote on the dev@ list, then repeat it on general@incubator once the first passes.
• Update the podling’s release checklist or wiki page with explicit steps and templates for cross-list voting.Mentors should confirm that both votes have concluded before declaring the release officialso both steps happen before announcing the result.

...

Scenario: The Off-List Decision

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

...

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

...

A podling has been active for several months, with regular commits, discussions, and releases happening regularly. However, one of its listed mentors hasn’t posted to the mailing list in nearly half a year. When the quarterly report is due, the remaining mentors realize they’ve been the only ones signing off. The absent mentor’s name is still listed, but they haven’t responded to pings or voted on any releases.

...

1. What should the remaining mentors and PPMC do in this situation?
2. How might mentor inactivity affect podling oversight and readiness for graduation readiness?
3. What steps can the IPMC take to ensure mentorship coverage stays healthy?

...

• The active mentors should contact the silent mentor privately to confirm whether they wish to continue.
• If there’s no response, the PPMC can request that the IPMC retire the mentor and invite another with complementary skills.
• Encourage periodic mentor check-ins, even brief “+1, still here” notes, to help maintain trust and visibility.

...

During a disagreement over release timing, a mentor tells the podling to “wait for my approval before proceeding.” Several PPMC members feel uneasy, they thought the project was supposed to be self-governing.
The mentor later explains they only meant to ensure the ASF policy was followed, but the tone created confusion about authority.

...

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

...

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

Possible path forward

• Encourage contributors to disclose their relevant affiliations when relevant, especially in discussions threads where corporate interests may overlap with community decisions, as this supports the perception of neutrality.
• 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.

...

• 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 that they represent the full entire picture, including any challenges.
• If a report omits serious issues, mentors can follow up on the mailing list and suggest a correction corrections or clarificationclarifications.
• Encourage the PPMC to discuss concerns openly before each report, so potential problems are recognized and documented early.
• Reports should accurately reflect reality, including any problems, and should not be generated by AI.

...

Scenario: Unrealistic Expectations of ASF Infrastructure

In one podling, contributors became frustrated when requests for setting up mailing list setup lists and website publishing websites 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.

...

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.

...

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

...

Possible path forward

• Choose mentors based on their engagement, availability, and complementary experience, not rather than their reputation or affiliation.
• 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 discussions were dominated by a few individuals dominated discussions. Although these issues persisted for several quarters, the prodling did not report them, 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 how long about the extent of the problems had existed, and the vote was postponed pending corrective action.

...

• Mentors should inform the IPMC early promptly when a podling shows exhibits sustained inactivity, release delays, or governance problemsissues.
• 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 communication helps protect both the podling and the wider community.

...

1. What signals show that new contributors are being welcomed—or welcomed or overlooked?
2. How can the community ensure that contributions receive timely and public acknowledgment?
3. What small steps can mentors or committers take to lower the barrier from “first PR” to “regular contributor”?

...

• 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, and set stronger norms than formal rules.

...

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 the 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?

...

After months of preparation, a podling submits its graduation resolution to the Incubator PMC for a vote. Most responses are +1, but one IPMC member objects, claiming “the community is still too small.” The podling feels frustrated. They’ve followed every step, have a working governance model, and just completed a successful release. Mentors wonder how to strike a balance between encouraging and respecting IPMC oversight.

...

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 appears that a company involved in the project is misusing their its brand. The podling feels frustrated, why . Why are these issues surfacing only now? 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 . 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.

...

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 details, they are part of ASF’s legal and quality framework.

...

A project has recently graduated and is proud of its new PMC. Several mentors who had helped through during the incubation period 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 a healthy , a sign of independence, while ensuring that knowledge remains accessible.

...

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

...