potiuk opened a new issue, #45: URL: https://github.com/apache/comdev/issues/45
Magpie ships `committer-onboarding`, which takes a nominator from a passed vote to a welcomed committer. One procedure serves both podlings and TLPs, branching on a `stage: podling | tlp` config key. ## The problem The values that branch selects — the Whimsy roster URL, the binding-vote rule, the private-list address — are filled in **per project, by hand**. Every project retypes what ComDev already knows, and when something changes, every copy is silently stale. `whimsy_roster_url: TODO` appears in our config template because there is nowhere better for it to come from. ## The proposal — two things ComDev would own, both optional ### 1. A value set One small file describing what being a graduated TLP implies: ```yaml stage: tlp governing_body: PMC whimsy_roster_url: https://whimsy.apache.org/roster/committee/<project> private_list: private@<project>.apache.org ``` Values only — no procedure, no prose. Magpie pins it by tag and resolves `project → stage → organization → default`, so a project gets correct defaults and can still override anything it genuinely needs to differ on. ### 2. An override, if values are not enough If ComDev concludes the shared procedure is simply wrong for TLPs — a step missing, a step ordered differently, a different tone — you write that in your own repository as an [agentic override](https://github.com/apache/magpie/blob/main/docs/setup/agentic-overrides.md), and every project picks it up on the next pin. No pull request against Magpie, and no second copy of the 80% that never diverged. The point is that divergence stays incremental: you are not choosing between "accept Magpie's procedure as-is" and "fork it". ## What we are asking Whether ComDev is willing to own these, and whether the values above are right. We have deliberately **not** written them ourselves. Magpie asserting what ComDev's policy is would recreate exactly the staleness this is meant to fix — we would find out we were wrong from a project that got it wrong. ## Context This would be the first time Magpie consumes a configuration fragment from ComDev. The Incubator PMC is already a source Magpie consumes from — their `releasecheck` skill arrives pinned by tag through a curated source — so the trust and pinning machinery exists and is in use; ComDev would be the second body using it. Design: https://github.com/apache/magpie/pull/1265. Nothing is built; this needs your answer first. Cross-posted to `[email protected]`. --- *Filed by a Magpie maintainer, drafted with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
