Hi - My remarks here are about ownership and not meant to be negative about these efforts. It’s also important to assess the LLM and token use in order to evaluate automation possibilities.
1. Roster / committer on boarding. I know that many PMCs have their own procedures and variations on the process while many do not. I think that the skill you are offering here is likely to undergo some changes especially since a replacement to Whimsy’s roster tool is a likely next tooling project. (That’s a good thing.) I really have no opinion about the best PMC to own the Magpie skill. 2. Release checker. I think that the release checker is a tool that will have foundation wide benefit. It seems like a great idea, but so far as I know we only have Justin’s word about the results. I might be wrong, but I would like to see some example output and do some of my own quality checks. How well the checker does is much more to me a Legal Affairs concern than it is the Incubator. I’ve expressed that it would be a good additional check to add to ATR either after or during the Glasgow conference. Automation question: I don’t think a frontier LLM is needed for these skills, what is the minimum LLM needed for each? Best, Dave > On Sep 17, 2026, at 4:26 AM, Jarek Potiuk <[email protected]> wrote: > > Replaced with proper Incubator email. > > On Thu, Sep 17, 2026 at 1:24 PM Jarek Potiuk <[email protected]> wrote: > >> 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]
