This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git
The following commit(s) were added to refs/heads/main by this push:
new ef33f1a7 docs(mission): clarify scope boundaries and non-goals (#485)
ef33f1a7 is described below
commit ef33f1a74cb740657c1d349a1ad83dfda4d3b483
Author: Jarek Potiuk <[email protected]>
AuthorDate: Sun Jun 14 11:57:13 2026 +0200
docs(mission): clarify scope boundaries and non-goals (#485)
Add a "Scope boundaries — what Magpie is, and the non-goals" section to
MISSION.md. It states that Magpie serves any project (ASF or not), is an
independent PMC that only releases software and sets no Foundation-wide
policy, works with rather than absorbs ComDev/Incubator/Security/Tooling,
keeps the data layer (MCPs) shared while letting skills diverge, embraces
duplication for decoupling, and treats mentoring as tooling rather than a
claim on ComDev's (and the Incubator's) community-development role.
Generated-by: Claude Code (Opus 4.8)
---
MISSION.md | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/MISSION.md b/MISSION.md
index fd482f11..ef08d56b 100644
--- a/MISSION.md
+++ b/MISSION.md
@@ -8,6 +8,7 @@
- [Proposal](#proposal)
- [Name](#name)
- [Rationale](#rationale)
+ - [Scope boundaries — what Magpie is, and the
non-goals](#scope-boundaries--what-magpie-is-and-the-non-goals)
- [Initial Goals](#initial-goals)
- [Technical scope](#technical-scope)
- [Maintainer education — building agentic projects is a different
craft](#maintainer-education--building-agentic-projects-is-a-different-craft)
@@ -71,6 +72,22 @@ Four design choices set the project apart from "just bolt a
code-review bot on i
**Development-cycle skills sit alongside maintainership skills, with
mentorship intrinsic to them.** Maintainers also write code; contributors live
the development side of every project. The same agentic primitives that triage
an inbound report or mentor a new contributor compose into a committer's or
contributor's own development cycle: multi-agent review pipelines that catch
issues before submission, self-review patterns that pre-flight a PR against
project conventions, scoped agent-dr [...]
+## Scope boundaries — what Magpie is, and the non-goals
+
+Magpie's scope is broad on *capability* and deliberately narrow on
*authority*. A platform this wide invites a fair question: does it overlap
ComDev, the Incubator, the Security team, Tooling, or the Responsible AI
Initiative, and where does the line actually sit? It is easy to misread Magpie
as another foundation-level body in that mould. It is not, and the line is
clean:
+
+**Magpie serves any project, ASF or not — that is the distinguishing line.**
Cross-foundation reach is a founding principle, not a later expansion. ComDev,
the Incubator, the Security team, Tooling, and the Responsible AI Initiative
are ASF-internal bodies that serve ASF projects. Magpie is not one of them and
does not aspire to be — a community that has never heard of the ASF is a
first-class adopter.
+
+**Magpie is an independent PMC like any other — all it does is release
software.** It does not set Foundation-wide policy. It does not decide what ASF
projects should or must do — on automation level or anything else. Telling
projects how to govern themselves is an explicit **non-goal**. The platform
makes a range of automation levels possible without picking one; each project
opts in, mode by mode.
+
+**Magpie works with the ASF bodies it overlaps — it does not absorb them.**
Where ComDev, the Incubator, Security, Infrastructure, or Tooling have relevant
skills, Magpie either helps implement them or *proxies* them. Those teams
choose whether to contribute a skill into Magpie or keep it in their own
repository and let Magpie install it by reference — Magpie does not reach into
another team's domain on its own initiative. Other foundations (e.g. Eclipse,
the Python Software Foundation) [...]
+
+**The data layer is shared; the skills on top are free to diverge.** This is
the boundary rule that makes the above work in practice. Shared MCPs and data
tools — PonyMail, Apache Projects, Trademark, and the like — stay centralized,
typically in ComDev or the Incubator, because divergence there means *wrong
data*, with no governance opinion to fight over. The skills built on top are
free to diverge by scope, tier, and teaching voice. DRY pays on the data tools;
it does not pay on the sk [...]
+
+**Duplication is embraced where it buys decoupling.** Working across
distributed, independent PMCs — and across foundations — makes some duplication
inevitable, and agentic tooling makes it cheap: an agent can reconcile two
near-identical skills on demand, so the price of keeping them separate is low
and the coupling avoided is real. Magpie does not chase DRY across
organisational boundaries. The one place divergence is *not* tolerated is the
**safety baseline** — the untrusted-content-i [...]
+
+**On mentoring specifically:** Magpie ships mentoring *skills* — reusable,
machine-assisted tooling any project can adopt — it does not own the
community-development mentoring function, which remains ComDev's (and, for
podlings, the Incubator's) for ASF projects. The Mentoring mode is a tool in
the box, not a claim on the role. The same framing applies to every mode:
Magpie supplies the agentic capability; the project, and where relevant the
responsible ASF body, keeps the policy.
+
## Initial Goals
- Stand up `github.com/apache/magpie` with project skeleton, CI, and
contributor docs.
