1. Welcome

Congratulations on joining the Podling Project Management Committee (PPMC)!
As a PPMC member, you are helping guide your podling through incubation and toward becoming a successful Apache Top-Level Project (TLP).

This guide outlines your role, expectations, and the support structure available to you.

2. What Is a PPMC?

  • PPMC = Podling PMC. Every incubating project has one.
  • The PPMC manages the day-to-day community and technical decisions of the podling.
  • Unlike a TLP’s PMC, the PPMC is still overseen by the Incubator PMC (IPMC) until graduation.

Key difference from a committer:

CommitterPPMC Member
Votes on code changesVotes on releases, new committers, reports
Writes code/docsGuides community, ensures ASF culture
Focused on contributionsFocused on governance

3. Responsibilities of a PPMC Member

  1. Community building

    • Welcome new contributors.
    • Encourage consensus-driven decisions.
    • Model ASF culture: transparency, meritocracy, respect.

  2. Project oversight

    • Participate in discussions on the podling’s private and dev lists.
    • Help plan releases, roadmaps, and community activities.

  3. Release voting

    • Podling releases must be approved by both the PPMC and the IPMC.
    • Learn the ASF’s release process (licenses, NOTICE, distribution).

  4. Reporting

    • Help draft reports for the Incubator (monthly at first, then quarterly).
    • Highlight progress and challenges honestly.

  5. Graduation readiness

    • Ensure the project is diverse, sustainable, and follows ASF policies.
    • Prepare for the transition to a TLP PMC.

4. Communication & Transparency

  • Use public mailing lists for most discussions.
  • Private list (private@podling.incubator.apache.org) is for sensitive topics only.
    Decisions about releases, new committers, or adding PPMC members must be made on the mailing lists, not on Slack, GitHub comments, or in private chats.

5. Decision-Making

  • Follow the Apache Way: consensus, community over code.
  • Binding votes in a podling come from PPMC members + mentors.
  • Most decisions should be made by lazy consensus (silence = agreement).
    Formal votes, such as for new committers, releases, or graduation, should last at least 72 hours. In rare cases, they can be shorter if there is a clear reason.

6. Joining and Growing the PPMC

  • New PPMC members are elected by a majority approval vote on the podling’s private list.
  • The process:
    1. A PPMC member nominates a candidate.
    2. A formal vote is held (should run at least 72 hours).
    3. If approved, the nominee is invited to join the PPMC (via the private list).
    4. The nominee responds to accept (on the private list).
    5. The nominee is added to the podling’s roster.

⚡ Tip: Be sure to document nominations, votes, invitations, and acceptances carefully. These records are important when your project is ready to graduate.

7. Adding New Committers

  • Committers are added by a majority approval vote on the podling’s private list.
  • The process is similar to PPMC membership but with one key difference:
    • The invitation and acceptance happen on the public dev list, not private.
  • Steps:
    1. Nomination by a PPMC member.
    2. Majority vote on the private list (should run 72h).
    3. If approved, the invitation is sent to the nominee.
    4. The nominee publicly accepts on the dev list.
    5. Infrastructure creates the account and updates commit access.

⚡ Remember: Adding committers helps your project grow its contributor base. This is one of the most important parts of incubation.

8. Working with Mentors

  • Each podling has 2–3 people assigned as mentors.
  • Mentors must be members of the Incubator PMC (IPMC).
  • Their job is to bridge the gap between your podling and the wider ASF.

What mentors do for you:

  • Help the PPMC learn ASF processes.
  • Provide early feedback before the IPMC sees something.
  • Serve as the first point of escalation if the community encounters challenges.
  • Model ASF culture: transparency, consensus, respect.

What mentors don’t do:

  • They don’t make decisions for your podling.
  • They don’t block progress unless ASF policies are clearly being broken.
  • They do not replace the PPMC. The PPMC is expected to lead.

9. The Role of the IPMC

  • The Incubator PMC (IPMC) oversees the entire Incubator and all podlings.
  • It ensures podlings follow ASF principles and are making progress toward independence.
  • The IPMC is accountable to The ASF Board for podling oversight.

What the IPMC does for you:

  • Reviews and formally approves podling releases.
  • Ensures your podling is building a healthy, diverse, and sustainable community.
  • Provides guidance on ASF policies (licensing, branding, governance).
  • Ultimately, votes on whether your podling is ready to graduate to a TLP.

You can think of the IPMC as your training wheels. They do not run your project, but they help make sure you are ready to move forward on your own.

10. The ASF Board

  • The ASF Board of Directors provides overall governance for the Foundation.
  • The Board does not run individual projects. That responsibility belongs to PMCs and PPMCs.
  • For podlings, the Board relies on the IPMC to provide oversight.
  • Podling reports are submitted to the Board via the IPMC.

What this means for you:

  • As a PPMC member, you won’t normally interact with the Board directly.
  • Your responsibility is to help write accurate podling reports so the IPMC can pass them along.
  • Once your podling graduates and becomes a TLP, your new PMC will report directly to the Board every quarter.

⚡ Key takeaway: The Board trusts podlings to govern themselves. Until graduation, it relies on the IPMC and mentors to make sure your project stays on track

11. Reporting in Practice

  • New podlings report monthly for the first three months.
  • After that, if things are stable, they report quarterly to the Board (via the IPMC).
  • Reports describe community growth, releases, and any challenges.

Good report:

  • Honest about issues (e.g., “low activity, need more committers”).
  • Highlights successes (new committers, releases).
  • Shows progress toward graduation.

Poor report:

  • Just “Everything is fine.”
  • No details on activity or community.
  • Omits challenges.

⚡ Why it matters: The Board learns about podlings through these reports. Accurate reporting helps The ASF provide support for your project.

12. Release Shepherding

  • PPMC members are responsible for helping podlings produce compliant releases.
  • Common pitfalls include:
    • Missing or incorrect LICENSE/NOTICE files.
    • Including non-compliant dependencies.
    • Forgetting the incubation disclaimer.
  • Mentors can help review, but PPMC members should actively check before calling a vote.

13. Incubation Disclaimer

  • All podlings must include the incubation disclaimer on their website and in every release.
  • This must remain until graduation.
  • The disclaimer makes it clear that the project is not yet a full ASF Top-Level Project.

14. Graduation Proposal Process

Graduation does not happen automatically. The PPMC needs to take the lead:

  1. Draft a graduation resolution.
  2. Discuss and vote on it within the PPMC.
  3. Send the resolution to general@incubator.apache.org for IPMC discussion and vote.
  4. If it passes, the resolution goes to The ASF Board agenda.

⚡ Graduation requires consensus that the podling can self-govern as a TLP.

15. Podling Branding

  • Podlings must follow ASF branding rules:
    • Use “Apache [Podling] (incubating)” in names and websites.
    • Include trademark disclaimers where appropriate.
    • Use the ASF logo only as permitted.
  • PPMC members should regularly check that the podling’s website, GitHub repos, and documentation comply.

16. Security and Privacy Basics

  • Podlings should handle security responsibly.
  • PPMC should ensure that sensitive data is not exposed and that The ASF privacy policy is respected.
  • If in doubt, ask mentors or raise a question on general@incubator.apache.org.

17. Escalation and Conflict Resolution

If problems arise, follow this escalation path:

  1. Discuss openly on dev@.
  2. If unresolved → bring to mentors.
  3. If mentors don’t respond → raise on general@incubator.apache.org.

18. Code of Conduct & ASF Culture

  • The ASF Code of Conduct applies to podlings just like TLPs.
  • PPMC is the first line of handling CoC concerns.
  • Escalation can go to mentors, the IPMC, or ASF leadership if needed.
  • Remember the Apache Way: assume good faith, act with respect, and put community over code.

19. Common Activities for New PPMC Members

  • Vote on a new committer proposal.
  • Review and test a release candidate.
  • Write or review a podling report draft.
  • Welcome a new contributor on the dev list.
  • Raise a question to mentors or the IPMC when unsure.

20. Time Commitment

  • Varies by podling activity — usually a few hours a month.
  • Expect more during release reviews and graduation prep.
  • Staying engaged and responsive is more important than the volume of emails.

21. Good Practices

✅ Be welcoming. New contributors are the future of the project.

✅ Be transparent. Decisions must be archived on mailing lists.

✅ Learn ASF policies (licenses, branding, voting).

✅ Document your reasoning when you cast a -1 vote.

✅ Ask questions. Nobody expects you to know everything on day one.

22. FAQs & Scenarios

Q: What if mentors don’t respond?
A: Raise the issue on general@incubator.apache.org. The IPMC can help, and other members often step in to help.

Q: What if the IPMC disagrees with our PPMC vote?
A: This can happen. The IPMC has the final say until graduation. Treat feedback as guidance to help the podling align with ASF practices.

Q: What if our first release fails IPMC vote?
A: This is common. Podlings often miss licensing, NOTICE, or packaging details the first time. Use feedback to quickly fix issues. Learning the process is part of the incubation phase.

Q: What if we can’t get enough +1 votes on a release?
A: A release needs at least three binding +1 votes from PPMC/IPMC members. If you don’t get them, ask mentors for help, or request more reviewers on general@incubator.apache.org.

Q: What if someone casts a -1 vote on a release?
A: A -1 is not a veto, but it indicates a serious concern. Address the issue, fix it if needed, and then re-run the vote with a new release candidate.

Q: What if we don’t have enough diversity to graduate?
A: Keep building. Graduation isn’t only about code — it’s about showing your community can sustain itself long-term, with contributors from multiple backgrounds and organizations.

Q: What if community discussions move off-list (e.g., to Slack or GitHub)?
A: Remind contributors that decisions must be made on the mailing list for transparency and archival. Side channels are fine for brainstorming, but official votes and decisions must be on-list.

Q: What if we miss a podling report?
A: The IPMC will notice. It’s not fatal, but repeated missed reports signal weak community oversight. Prioritize catching up quickly.

Q: What if we don’t get mentor sign-off on the report?
A: Then the report won’t be submitted. It’s the mentor’s role to approve reports before they are forwarded. If sign-off is delayed, follow up with your mentors early and often to avoid missing deadlines.

Q: What if our mentors become inactive?
A: Raise it on general@incubator.apache.org. The IPMC can help re-engage mentors or assign new ones if needed.

Q: What if most contributors are from one company?
A: This is common early in incubation. Actively encourage contributions from outside organizations, and document progress in reports. Diversity of affiliation is required for graduation.

Q: What if we’re late submitting a report?
A: Submit it as soon as you can. One late report is not a big issue, but repeated delays raise concerns about project oversight.

Q: What if our community feels “stuck” in incubation?
A: Talk to your mentors and the IPMC. Many podlings take years to graduate, but steady progress and honest reports will keep the community moving forward.

Q: What if our podling decides to retire?
A: Retirement is a valid outcome. The PPMC should discuss and vote on it, then work with mentors and the IPMC to finalize the project's closure.

Q: What if our podling wants to use GitHub Issues instead of JIRA?
A: That’s fine. The ASF supports both. The PPMC should decide what best fits the community, but decisions must still be captured and archived on the mailing list.

Q: What if conflict arises in the community?
A: Use ASF values: respect, consensus, and transparency. Encourage calm, public discussion. If conflict persists, mentors can mediate; unresolved issues can be raised on general@incubator.apache.org.

23. Next Steps

As a new PPMC member, you should:

  1. Subscribe to your podling’s dev@ and private@ mailing lists.
  2. Read recent discussions to understand context.
  3. Introduce yourself briefly to the community.
  4. Review the Incubator website: https://incubator.apache.org.

24. Resources

⚡ Reminder: The goal of incubation is about more than just code. Graduation happens when your podling shows it can self-govern the community the Apache Way.

  • No labels