Dear Incubator PMC and Community Development Teams,
I am writing to both groups because this proposal addresses shared
responsibilities where neither part functions effectively on its own.
We have two main questions regarding Apache Magpie governance and
release skills:
=====================================================================
QUESTION 1: Would you own the governance values?
THE PROBLEM
Apache Magpie includes a committer-onboarding skill that guides
nominators through the committer onboarding process. A single
procedure serves both incubating podlings and top-level projects
(TLPs), branching via a stage: podling | tlp configuration key.
Currently, values for Whimsy roster URLs, voting rules, private lists,
and governing bodies are entered manually per project. This leads to
duplicate efforts and stale configurations (e.g., our configuration
template currently defaults to whimsy_roster_url: TODO).
PROPOSED SOLUTION
We propose establishing central value sets and allowing local overrides:
1. Centralized Value Sets:
- Incubator PMC owns podling defaults:
stage: podling
governing_body: PPMC
whimsy_roster_url: https://whimsy.apache.org/roster/ppmc/<project>
private_list: private@<project>.incubator.apache.org
vote_rule: 3 binding PPMC +1s, no binding veto
binding_voters: current PPMC members
- ComDev owns TLP defaults:
stage: tlp
governing_body: PMC
whimsy_roster_url: https://whimsy.apache.org/roster/committee/<project>
private_list: private@<project>.apache.org
Magpie will resolve these defaults automatically while allowing
project-level overrides.
2. Agentic Overrides:
If specific procedural differences are required (e.g., IPMC
notifications or additional checks), they can be maintained directly
in your respective repositories without modifying Magpie and release
it separately:
https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md
=====================================================================
QUESTION 2: Would either group prefer to own the release skills
directly?
Magpie includes ten ASF-scoped release skills (rc-cut, verify-rc,
vote-draft, vote-tally, promote, announce-draft, keys-sync,
archive-sweep, audit-report, prepare).
Currently, these skills do not distinguish between podlings and TLPs,
meaning podlings using them are guided through an incomplete process
(missing podling/IPMC nuances).
Given that skills can now be published independently (e.g., via claude
plugin marketplace add apache/incubator), would the Incubator PMC or
ComDev prefer to own these release skills directly? Magpie can
maintain registry discovery - while still acting as a pass-through for
those who install / adopt Magpie.
===================================================================== NEXT STEPS
We are seeking input on:
1. Whether each group is willing to own its respective governance
values (Question 1).
2. Whether either group wants to own part or all of the release
skills family (Question 2).
Additional details and design discussions are available here:
- Design PR: https://github.com/apache/magpie/pull/1265
- ComDev Tracker: https://github.com/apache/comdev/issues/45
Please let us know your thoughts.
Best regards,
Jarek Potiuk
--
Drafted with AI assistance (Claude Opus 5) and reviewed before sending.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
