Rich, Jarek, all, +1 on Option 2. One distinction that I think dissolves the duplication worry:
`next-committer` and Magpie's `contributor-nomination` aren't the same skill. `next-committer` sweeps a **whole project** to surface people nobody named yet (discovery, a ComDev concern). The Magpie skills take **one known handle** and build the vote evidence (per-candidate workflow). They chain rather than overlap: one finds the names, the other works each up. The only real overlap is the data layer: ponymail-mcp and apache-projects-mcp. That gives the boundary rule worth writing down: **shared MCPs stay centralized, skills on top are free to diverge.** DRY pays on the data tools (divergence there = wrong data, no governance opinion to fight over). It doesn't pay on skills, where scope, tiers, and teaching voice legitimately differ. So share the MCPs, duplicate the skills. For Option 2's "Magpie proxies and installs" to work without breaking on every rename, the proxy needs a contract, and the [taxonomy thread]( https://lists.apache.org/thread/rckckmc50hl3z33yxz5rkszs1k7gf5w5) already has its shape: tag each skill (`domain`, `audience`, `risk-tier`, `source`), reconcile intent against the registry, ship renames as migration entries. Tag `next-committer` as `source: asf-comdev` and the nomination skills as `source: asf-incubator`, and the split above becomes a query, not tribal knowledge. On "AI makes DRY less valuable": agreed, but silent divergence is divergence nobody reviewed. So let skills drift on scope and voice, stay eventually-consistent only on the safety baseline: untrusted-data / prompt-injection rule (Magpie has it in AGENTS.md, `next-committer` doesn't yet per Justin's review), identity-resolution caveats, confidentiality up front. Concrete proposal: 1. Keep both MCPs where they are. 2. Land `next-committer` in ComDev, but align it with Magpie on the safety baseline. 3. Tag both into the registry with `source`/`audience` so Magpie installs them via the reconciler. Happy to do the tagging pass and write up the safety baseline if there's appetite. André Em qui., 4 de jun. de 2026 às 17:39, Jarek Potiuk <[email protected]> escreveu: > Correction: > > * "magpie-asf-incubator-candidates" > * "magpie-asf-comdev-commiter-candidates," > > As an example set of similar SKILLs. > > On Thu, Jun 4, 2026 at 10:37 PM Jarek Potiuk <[email protected]> wrote: > > > Hi Rich, > > > > This is an excellent question. > > > > Currently, we work effectively with ComDev for MCPs (PonyMail / Apache > > Projects - and we can also add Trademark and other MCPs from > > Incubator). I see a natural split emerging where MCPs reside in ComDev > > or the Incubator, while Magpie focuses on the workflow infrastructure > > and "SKILLS" to run them. > > > > I see two primary ways we could proceed regarding the ownership and > > location of these skills: > > > > 1) Joint Maintenance in Magpie: Since several founding members here > > are also in ComDev and the Incubator, we could pragmatically update > > skills within Magpie together. While this avoids duplication, it > > carries a risk of tension if different groups have conflicting views > > on governance or teaching styles > > > > 2) Decoupled sets of SKILLS: We could have distinct sets of skills > > marked as "asf-incubator" and "asf-comdev." These would be maintained > > by their respective teams in their own repositories, and Magpie would > > simply proxy and install them by default for ASF projects. This > > approach aligns with our goal of keeping Magpie agnostic of specific > > organizational governance. It also allows the Incubator and ComDev to > > maintain their unique perspectives—for instance, focusing on trademark > > checking or initial "teaching" versus reinforcing established > > practices. Yes - there will be some duplication - but if duplication > > means we avoid tension when reconciling things, I think that's fine. > > There might be similar SKILLs, for example, > > "magpie-asf-incubator-candidates" and > > "magpie-asf-incubator-commiter-candidates," that would be similar but > > not necessarily the same. > > > > Personally, I lean towards Option 2. > > > > It reduces potential tension between PMCs and sends a clear signal to > > external users that Magpie is not "Apache-only," while still allowing > > groups to share underlying data tools like the Ponymail or Apache > > Projects MCPs and to use Magpie's infrastructural pieces - like > > security/isolation/privacy/update and installation and adoption > > mechanisms. > > > > One more thing makes Option 2 more appealing. This also relates to why > > we traditionally believe (as we were taught throughout our engineering > > journey) that DRY is almost universally a good thing. I've always had > > an issue with this, because the price you pay for DRY is increased > > coupling, meaning you must agree on things before making them DRY—it's > > always a trade-off. And what I've learned is that AI/Agents make DRY > > far less valuable. We can always ask an agent to reconcile things, > > find and fix commonalities and leave things in two or more places. > > Yes, they might diverge, but then we can make them "eventually > > consistent" - in places that matter, not across the board. > > > > This also ties into our ongoing discussion regarding the adoption > > journey and taxonomy: > > https://lists.apache.org/thread/rckckmc50hl3z33yxz5rkszs1k7gf5w5 > > (https://lists.apache.org/thread/rckckmc50hl3z33yxz5rkszs1k7gf5w5) - > > it might be good input to "intent" approach - and whether "family" is > > a good "unit of adoption". > > > > I would love to hear what others think about this separation of scopes. > > > > Best regards, > > Jarek > > >
