Ok, that’s reasonable. I’ll continue to focus my ComDev hat on tools/info/advice/documentation for projects under the ASF umbrella, and not worry about duplication too much.
> On Jun 10, 2026, at 5:57 AM, Jarek Potiuk <[email protected]> wrote: > > 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 >> >> >>
