...

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

...

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

...

Mentoring and Oversight

Mentors are the bridge between a podling and the Apache Software Foundation. Their role is not to direct the project, but to guide it toward self-governance, ensuring the community learns to make decisions transparently, respect ASF policy, and maintain healthy dynamics.

...