Does this work for you? https://github.com/apache/comdev/tree/main/governance
> On Sep 18, 2026, at 11:30 AM, Jarek Potiuk <[email protected]> wrote: > > Correct - for the "parameters" - it's as easy. If we decide that some of > the SKILLs should be "managed" by Comdev/ Incubator - this is also more "we > want to keep it updated" - this is what happens now with the Incubator > SKILL - any updates there can be done without Magpie's involvement - maybe > when new version appears we pin to it. > > J. > > > On Fri, Sep 18, 2026 at 4:04 PM Rich Bowen <[email protected]> wrote: > >> Not sure I’m following all of the objections, but as I understand this, >> it’s a pretty simple ask - that we stash a file in our git repo as a source >> of truth, yes? >> >> I propose we put the file in github.com/apache/comdev under a governance/ >> directory — something like governance/tlp-governance-defaults.yaml. That >> gives us a natural place to maintain it, and anyone on the ComDev PMC can >> update it via PR. Does that work for you? >> >> I'll put a starter file there shortly so you have something concrete to >> point Magpie at. If the shape of the YAML needs to change to fit your >> schema, just open a PR or an issue and we’ll sort it out. >> >> On the release skills question — I agree with Justin that overrides are >> the right approach. We don't need to own separate copies of skills that are >> 95% identical. >> >> How’s this to start: >> >> >> >> # organizations/ASF/stages/tlp.md — sourced from apache/comdev >> stage: tlp >> pmc_of_record: PMC >> delegated_body: PMC # same body for TLPs >> whimsy_roster_url: https://whimsy.apache.org/roster/committee/<project> >> private_list: private@<project>.apache.org >> >> votes: >> committer: >> list: private@<project>.apache.org >> binding_voters: PMC members >> rule: at least three +1s, and more +1s than -1s >> release: >> - list: dev@<project>.apache.org >> binding_voters: PMC members >> rule: at least three +1s, and more +1s than -1s >> publishes: true >> >> >> —Rich >> >> >>> On Sep 18, 2026, at 6:24 AM, Jarek Potiuk <[email protected]> wrote: >>> >>> Hi Justin and Dave, >>> >>> Thank you both for the feedback. >>> >>> Justin, >>> >>> You are correct on all four podling value corrections: >>> >>> - private_list: private@<project>.apache.org (mine was stale). >>> - vote_rule: Must have at least three +1s and more +1s than -1s. >>> - governing_body: IPMC is the PMC of record; the PPMC is delegated. >>> - binding_voters: Depends on the vote (PPMC members on the podling's >>> list; IPMC members on general@). >>> >>> The last two represent a modeling error on my part. I designed >>> governing_body and binding_voters assuming a single governing body per >>> podling, but authority depends on which list the vote takes place on. >>> A single key per project cannot express this, so I will update the >>> design to specify bodies per action before building. >>> >>> Regarding Question 2, I agree and will drop the "move all ten" >>> framing. Most of the release procedure is identical for podlings and >>> TLPs. The podling deltas apply to vote-draft, vote-tally, verify-rc, >>> promote, and announce-draft. >>> >>> For releasecheck, it is already integrated via Magpie >>> (organizations/ASF/skill-sources.md, ref releasecheck-0.5.1), so >>> podlings can install it directly. I will document this recommendation >>> accordingly. For the other four skills, using podling overrides rather >>> than forked copies is the right approach. This allows the Incubator to >>> manage podling-specific procedures in its own repository and on its >>> own release cadence. >>> >>> What I Need Next >>> >>> To move forward and avoid stale configuration files copied across >>> projects, I am asking for body ownership: >>> >>> - Incubator PMC: Will you take ownership of the podling value set >>> (with the corrections above)? >>> - ComDev PMC: Will you take ownership of the TLP value set? >>> >>> If either group declines, I will remove the stage tier from the design. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
