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
