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