[PR] docs(designs): propose body-owned configuration layers [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk opened a new pull request, #1265:
URL: https://github.com/apache/magpie/pull/1265

   ## Summary
   
   Records a design that started as *"should podling onboarding move to `apache/incubator`?"* and ended somewhere else — because the answer is **no**: the thing that should move is not a skill.
   
   - **`committer-onboarding` already parameterises the podling/TLP difference** (`stage: podling | tlp`, `whimsy_roster_url`, …). The procedure is one procedure and the branch is data, which is right.
   - **What is wrong is that the data has no owner.** `whimsy_roster_url: TODO` is filled in per project, by hand, copying values the Incubator PMC holds centrally. Every podling retypes them; when the Incubator changes one, forty podlings are silently wrong; and graduation, which should be one line, is a rewrite.
   - **Proposes a body-owned tier** between organization and project config: an overlay describing what `stage: podling` implies, owned by the IPMC, and its TLP counterpart owned by ComDev — each sourced from its own repository by pin. Magpie resolves `project → stage → organization → default`.
   
   ## Type of change
   
   - [ ] Skill change (`.claude/skills/<name>/`) — eval fixtures updated below
   - [ ] Tool / bridge contract (`tools/<system>/*.md`)
   - [ ] Python package (`tools/*/` with `pyproject.toml`)
   - [ ] Groovy reference impl
   - [x] Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM) — configuration resolution, and a cross-PMC boundary
   - [x] Documentation (`docs/`, `README.md`, `CONTRIBUTING.md`)
   - [ ] Project template (`projects/_template/`)
   - [ ] CI / dev loop (`prek`, workflows, validators)
   - [ ] Other:
   
   ## Test plan
   
   - [ ] `prek run --all-files` passes
   - [ ] For Python packages touched: `uv run pytest` / `ruff check` / `mypy` passes
   - [ ] For Groovy bridges touched: command-line invocation tested end-to-end
   - [ ] For skill changes: eval suite passes for the affected skill
   - [ ] For skill *behaviour* changes: a new or updated eval fixture is included in this PR
   - [x] Other:
     - Documentation only. **Nothing is built** — the status line says so.
     - `prek run --files` clean, lychee included.
     - Every claim about current behaviour is checked against the tree: the `stage` / `whimsy_roster_url` keys in `projects/_template/committer-onboarding-config.md`, the `apache-incubator` source pin in `organizations/ASF/skill-sources.md`, and the whole-skill-only limit of `skills/<name>/source.md`.
   
   ## RFC-AI-0004 compliance
   
   - [ ] **HITL** — any new mutation is gated on explicit user confirmation
   - [ ] **Sandbox** — no new unrestricted host access; network reach declared in the adapter
   - [x] **Vendor neutrality** — the tier is organization-shaped, not ASF-shaped; a non-ASF adopter with two governance stages gets the same mechanism.
   - [x] **Conversational + correctable** — the overlay is optional by construction; a project that must differ still overrides, because project beats stage.
   - [ ] **Write-access discipline** — no autonomous outbound messages; drafts only, sent on confirmation
   - [ ] **Privacy LLM** — private content does not reach a non-approved LLM
   
   ## Linked issues
   
   Follows #1259, which curated `apache/incubator` as an ASF skill source.
   
   ## Notes for reviewers
   
   - **The ask of the Incubator is smaller than it first looks.** #1259 already curates `apache/incubator` as a pinned source, and `releasecheck` already arrives through it. This asks them to publish a second, much smaller artefact through an arrangement that exists and works — not to become a source for the first time. ComDev would be the first, which is worth being honest about.
   - **The alternatives section is the part to read.** In particular *"ship the overlays inside Magpie, maintained by us"* — cheap, tempting, and rejected, because it would have Magpie asserting what another PMC's policy is and learning it had changed from a podling that got it wrong.
   - **One mechanism is load-bearing and does not exist:** sourcing a configuration *fragment* from an external repo. `skill-sources` redirects a whole skill; there is no way to pin a config block. Without it the design collapses into copying the Incubator's values into our tree, which is the drift it exists to prevent.
   - **This needs two PMCs to agree before any of it is built.** Issues proposing it to the Incubator PMC and ComDev follow. If either declines, the fallback is the status quo for that stage rather than a broken framework.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] docs(designs): propose body-owned configuration layers [magpie]

["potiuk (via GitHub)" <gi...@apache.org>]

potiuk merged PR #1265:
URL: https://github.com/apache/magpie/pull/1265


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org