Proposal: own the TLP governance values Magpie's onboarding skill needs

Start with the committer-onboarding context, the linked design PR #1265, and docs/setup/agentic-overrides.md. This issue has no implementation or named test to run; it is done when ComDev decides whether to own the proposed TLP values and confirms whether they are correct.

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:

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, 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 dev@community.apache.org.

Filed by a Magpie maintainer, drafted with AI assistance.