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é >
