Hey Everyone! Hope you are doing well.
Thanks Jarek. You've got exactly the main objective of it. And we can adapt in the future, as the community is going to be bigger. For all fellows, any other thoughts about it? Or can we start a lazy consensus on this? Regards, André. Em ter., 2 de jun. de 2026 às 08:12, Jarek Potiuk <[email protected]> escreveu: > Hi André, > > Thank you so much for putting together such a detailed proposal and RFCs; > the organization is excellent. > > I truly appreciate how the intent-based model aligns with the way we work > as maintainers, and I'm excited to find the right level of granularity > together. So I think we should start a bit from concrete intents and see > how it maps to those taxonomies. > > I think our "number 1" focus should be prioritizing how we can fulfill the > intents of maintainers in our communities. > > To ensure a frictionless "Problem -> Solution" journey for everyone, it > might be helpful if we each shared what an ideal journey looks like for our > specific projects. > > For Airflow, I’ve been thinking about a few core intents that could help > our community thrive: > > - *Prioritizing high-value contributions* to help maintainers focus on > the most impactful work. > - *Building our community organically* by providing tools for meaningful > reviews and contributor growth. > - *Helping the community "hum"* by distributing activity fairly to > prevent any areas from being overlooked. > - *Facilitating ideation* and organizing issues to help prevent > maintainer burnout. > - *Ensuring reliability* through efficient and low-overhead management of > security fixes. > - *Improving maintainer "comfort" *by automating compliance with their > environment's security and privacy expectations. > > I’m really looking forward to seeing how these intents resonate with others > and how we can move forward with mapping them to our "taxonomy". > > > *Others - what are the intents that would make your projects to start using > Magpie ?* > Best, > Jarek Potiuk > > > On Mon, Jun 1, 2026 at 6:53 PM André Ahlert <[email protected]> wrote: > > > Hi all, > > > > I want to put a proposal in front of the list about how projects adopt > > Magpie, and about the primitive we organise the framework around. This > is a > > [DISCUSS] thread, not a vote. I have a working prototype, but nothing is > > decided and I want the list's read before anything moves upstream. > > The problem > > > > Today a project adopts Magpie by reasoning about modes (Triage, > Mentoring, > > Drafting, Pairing, Auto-merge) and families (security, pr-management, > ...). > > A new PMC has to internalise ~17 skills, 5 modes, several families and > the > > relationships between them before they can answer "what do we turn on". > The > > conversation lands on "do we enable family X" when the real question is > > "how much automation does our project actually want, and for whom". > > > > The deeper issue: modes are not one axis. The framework's own > docs/modes.md > > <https://github.com/andreahlert/magpie/blob/main/docs/modes.md> shows > it. > > Triage is listed as "stable (security) / experimental (pr-management, > > issue-management, ...)", one mode spanning two maturity states and four > > domains. pr-management-code-review is filed under Triage with a > hand-wave. > > security-cve-allocate admits it is "procedural rather than classificatory > > ... listed here for navigability". Pairing is defined by where the agent > > runs (dev-side vs project-side), Auto-merge purely by risk tier, > Mentoring > > is also a property of Pairing skills. Modes fuse at least three different > > axes (action/risk, audience, register) into one enum. That is fine as > > prose, lossy the moment you want to compute against it. > > The proposal (Model C: intent + lock, Terraform style) > > > > 1. Every skill carries machine-readable tags on explicit axes: domain, > > audience, risk-tier, integrations, requires. > > 2. An adopter writes a short intent file: domains, audiences, > > risk-tier-max, integrations, plus surgical overrides (exclude, > > force-include, pin, params). > > 3. A reconciler intersects intent against the skill registry and > emits a > > deterministic lock file (reproducible across machines) plus optional > > rendered templates. > > 4. plan / apply behave like Terraform: the adopter sees the diff > before > > anything writes. > > > > Onboarding then shrinks to four strategic questions (domains, audiences, > > risk-tier-max, integrations). The reconciler picks the skills. A skill > > rename ships as a migration entry and shows up in plan, so no adopter > ever > > grep-and-replaces. Structure becomes computable: "every write-comment > skill > > that touches gmail" is a one-line query over the registry index. > > > > Modes do not die. They survive as a projection over the taxonomy in > > MISSION.md and the adoption docs, where the narrative is genuinely > useful. > > They stop being the data primitive. > > Why this also helps the website > > > > If skills are tagged by audience and adoption path, the site can be > > organised around "what Magpie offers a maintainer / a contributor / a > > security team" instead of around internal mode names. The taxonomy and > the > > site information architecture become the same model. > > Evidence / prototype > > > > I built a fork to pressure-test this end to end: > > > > - Repo: github.com/andreahlert/magpie > > - Umbrella issue: #1 <https://github.com/andreahlert/magpie/issues/1> > > - RFC-MAG-0001 (adoption models A/B/C): RFC-MAG-0001 > > < > > > https://github.com/andreahlert/magpie/blob/main/docs/rfcs/RFC-MAG-0001-adoption-models.md > > > > > - RFC-MAG-0002 (structural impact of Model C): RFC-MAG-0002 > > < > > > https://github.com/andreahlert/magpie/blob/main/docs/rfcs/RFC-MAG-0002-model-c-structural-impact.md > > > > > - Working registry (29 skills tagged on all axes, with requires > edges): > > registry/skills-index.json > > < > > > https://github.com/andreahlert/magpie/blob/main/registry/skills-index.json > > > > > > > The fork is a prototype. It has rough edges I would clean before any > > upstream PR, and a self-written drift audit at docs/audit-drift-report.md > > < > > > https://github.com/andreahlert/magpie/blob/main/docs/audit-drift-report.md > > > > > documents where the fork diverges from current main. I am sharing it as > > discussion material, not a finished change set. > > What I am asking > > > > - Does the "modes conflate multiple axes" diagnosis read as real to > the > > people running adopters, or is it an edge-case annoyance? > > - If the taxonomy is right, is the full intent + lock + reconciler the > > proportionate mechanism, or do we want the structured registry first > and > > the reconciler as a follow-up? > > - Concerns about the migration cost for current adopters? > > > > I discussed an early version of this with Jarek offline and he suggested > > bringing it to the list. Keen to hear where people push back. > > > > Thanks, André > > >
