I opened a PR with MISSION update to capture those clarifications - https://github.com/apache/airflow-steward/pull/484 any and all comments are welcome - I will give it a bit of time to gather comments, I think it is important to clarify that we all have the same understanding :).
J. On Wed, Jun 10, 2026 at 4:08 PM Jarek Potiuk <[email protected]> wrote: > 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 >> >> >> >> >> >> >> >>
