I think we can definitely work out adapting our mission to clarify things. I believe we can draw a clear distinction - and I think both 1) and 2) way of integration very much address it.
* Magpie addresses any project, regardless of whether it is ASF or not - this is in our principles and this is an important part of our mission * Tooling, Incubator, Comdev, Security, etc., are all targetted to ASF projects In short: * Magpie is an "independent" PMC like any other—all we do is release software. We do not set Foundation wide policies, nor do we decide what ASF projects should or could do as a policy. This is a non-goal for us. * Magpie produces general workflows, and reusable tools that any project can use * Magpie works with Security, Infrastructure, Tooling, Comdev, and the Incubator to either implement or "proxy" the skills from the relevant areas. Particular teams in ASF might choose to either contribute to Magpie or proxy - if they feel it's useful for them to be part of Magpie, but we won't do it on our "own." Similarly, software foundations like "Eclipse" or "Python" software foundations or others - might contribute their own "tools" and "skills" to Magpie, proxy them, or even keep a separate integration on top of Magpie, or even use Magpie as inspiration. I think that is a clear line. I am personally not afraid of duplicating work - it's nearly impossible to avoid duplication when working with distributed, independent PMCs; it's absolutely bound to happen. Especially in the AI world, duplication is not a bad thing. It avoids coupling and coordination - and we should embrace it rather than prevent it. J. On Tue, Jun 9, 2026 at 7:42 PM Rich Bowen <[email protected]> wrote: > Thanks for the feedback. I’ve been giving this a lot of thought, and I > think it’s definitely important to draw lines (even fuzzy ones) around what > is still within the scope of community development, and what goes > elsewhere, like in Magpie. All of the mentoring language in the Magpie > MISSION.md feels possibly misplaced, as that’s within the scope of ComDev. > At the same time, every project should be doing mentoring, so that’s a very > fuzzy line. > > This also has me thinking about all of the other efforts that Magpie > overlaps - Tooling, Security, Incubator, the Responsible AI discussion all > come to mind. And the Magpie MISSION.md is very, very broad, making it hard > to understand if *anything* is out of scope. > > This isn’t about stepping on toes, but more about duplication of effort > and being sure that all the different groups are sufficiently aligned that > we’re not working against one another. As I’m coming to the discussion > fairly late, I want to be sure that this has been considered, and that > Magpie, in its enthusiasm, doesn’t try to do everything and ending up > losing track of the core mission. > > > On Jun 4, 2026, at 9:28 AM, Rich Bowen <[email protected]> wrote: > > > > Hi, friends, > > > > I’m still feeling like a beginner in my AI journey, but I’m trying to > create tools that make my own work easier. My hope is that these Magpie > skills/agents/whatever the correct term is, will make this work easier for > people like myself who don’t have deep understanding of how stuff works > behind the scened. > > > > Anyways, I made this skill: > > > > https://github.com/apache/comdev/pull/18 > > > > … over in the ComDev Repo, but wanted to mention it here, too. There’s a > handful of Ai-ish things in that repo already - the ponymail map and the > apache-projects mcp - and so I put this there too. But I want to avoid > duplication between the Comdev and Magpie in this regard, so wanted some > input regarding whether this stuff should (eventually?) be moved over here > instead, and simply referenced from Comdev. > > > > In addition to duplication, there’s also the concern of helping our > maintainers find everything they need in one place, rather than having to > go hunting several different places. > > > > Clearly (at least to me) “who is your next committer” is a project > community/governance concern (ie, community development) rather than a > project *maintenance* concern. But at the same time, there’s plenty of > overlap between those two things. > > > > So, anyways, would love to see some discussion about the separation of > scopes, and what you think about whether these skills should be here or > there. > > > > —Rich > > >
