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 >
