I can also update our mission to be very clear. I think our resolution is rather clear about it. Some of the doubt raised by people in the board discussion wasn't really because of the resolution's wording, but because they misinterpreted it, thinking that that Magpie is more like Incubator and Comdev - but ... we are not :D.
Having it clearly stated in our MISSION - might help to communicate this. J. On Wed, Jun 10, 2026 at 2:24 PM Rich Bowen <[email protected]> wrote: > 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 > >> > >> > >> > >
