docs(MISSION) + build(asf): add Paul King, day-one collaborators (#60) * docs(MISSION) + build(asf): add Paul King, day-one collaborators MISSION.md: - Add Paul King (Groovy PMC, Grails PMC, Incubator PMC) to the initial PMC roster. - Add a Non-ASF-members section listing the five contributors who will be involved on the project from day one even though they are not (yet) ASF members: Bartosz Sławkowski (@johnslavik), Yeongook Choo (@choo121600), Shahar Epstein (@shahar1), Vincent Beck (@vincbeck), Buğra Öztürk (@bugraoz93). .asf.yaml: - Add @johnslavik to the GitHub-collaborators list. The other four (@choo121600, @shahar1, @vincbeck, @bugraoz93) are already Apache Airflow committers and so already have triage rights via the apache GitHub org — no `collaborators:` slot needed; left in the file commented out as a record of intent. - Add the six non-Airflow-committer ASF members from the PMC roster (@ppkarwasz, @zeroshade, @andrewmusselman, @justinmclean, @jbonofre, @paulk-asert) so they have triage rights from day one. Airflow committers on the roster are not listed; they have access via the apache org through their existing committer status. Total active collaborators: 8 of the 10-entry cap, leaving headroom for the next addition without an Infra exception. Generated-by: Claude Code (Claude Opus 4.7) * chore(typos): allowlist `asert` (Paul King's GitHub-handle suffix) The typos hook flagged `paulk-asert` in `.asf.yaml` because it splits hyphenated identifiers and saw the trailing `asert` as a typo of `assert`. Add the suffix to `.typos.toml`'s `[default.extend-words]` block alongside the other ASF-specific allowlist entries. Generated-by: Claude Code (Claude Opus 4.7)
Table of Contents generated with DocToc
Heads-up — rename in flight, name not yet chosen. This repository is currently served from
apache/airflow-stewardand is going to be renamed to a different name — notapache/steward. The current name carriesairflowfor legacy reasons, but the framework is project-agnostic (it stewards multiple ASF project workflows, not just Airflow's), so the working group steering it will pick a new name that reflects that. The final name will be chosen by discussion followed by a poll among the working-group members.Current candidate names (the list is open for additions during the week of 4–9 May 2026, after which the poll opens):
- Apache Mentor
- Apache Reeve
- Apache Guild
- Apache Minerva
- Apache Magpie
- Apache Beacon
- Apache Compass
- Apache Lexicon
- Apache Polyglot
Until the rename lands on the GitHub side, every clone URL, git-submodule reference, and CI integration still uses the legacy
apache/airflow-stewardslug — all path examples in this README and the linked docs use that slug verbatim. The rename will only change the GitHub repository slug; existing checkouts will keep working with a singlegit remote set-url.
A reusable, project-agnostic framework for ASF-project automation. Currently in development for ASF projects + Python Core team friendlies. Not a public marketplace skill — adoption is by invitation while the framework is pre-release; once we ship via the ASF release policy, the marketplace path opens up. See release-distribution for the canonical distribution mechanism we will adopt.
[!IMPORTANT] The motivation, scope, and design commitments behind this work live in
MISSION.md— the draft project- establishment proposal for an Apache Top-Level Project built on this framework. Read that for the why; this README is the how once you've decided to adopt.
The framework uses a snapshot + agentic-override adoption model. An adopter project commits a single skill — setup-steward — into their repo. That skill manages everything else:
setup-steward downloads the framework into a gitignored <adopter>/.apache-steward/ directory. The snapshot is a build artefact, not source — refreshed by /setup-steward upgrade, never committed.setup-steward symlinks the framework‘s skills (security, pr-management, the rest of setup) into the adopter’s existing skill directory, matching whichever convention the adopter uses (flat .claude/skills/, or the double-symlink .claude/skills/<n> → .github/skills/<n>/ pattern apache/airflow uses). The symlinks are also gitignored — they target the gitignored snapshot, so they would dangle on a fresh clone before /setup-steward runs.<adopter>/.apache-steward-overrides/<skill>.md, committed in the adopter repo. The framework's skills consult those files at run-time and apply the overrides before executing default behaviour. See docs/setup/agentic-overrides.md for the contract.No git submodules. No marketplace. No vendored copies of framework skills. Just one committed skill (the bootstrap), a gitignored snapshot, and agent-readable override files.
Two phases — a shell bootstrap that gets setup-steward into your repo, then the skill takeover that wires up the rest interactively.
Pick an install method and follow the verbatim recipe in docs/setup/install-recipes.md:
| Method | When to use | Reproducibility |
|---|---|---|
svn-zip | Production once ASF official releases ship to dist.apache.org (signed + checksummed) | Frozen by version |
git-tag | Pin a specific framework version | Frozen by tag |
git-branch (default main) | WIP path — track the framework‘s main directly. The default during the framework’s pre-release phase. | Tracks tip |
Each recipe is a single shell block that:
.apache-steward/, .apache-steward.local.lock, and the framework-skill symlinks to .gitignore..apache-steward/ (gitignored — build artefact, not source).setup-steward skill into your skills directory, matching your existing convention (flat .claude/skills/<n>/ or the double-symlinked .claude/skills/<n> → .github/skills/<n>/ pattern).After the recipe completes, the framework snapshot is on disk and the bootstrap skill is in your repo.
Tell your agent: “adopt apache/airflow-steward in my repo” (or invoke /setup-steward directly). The skill walks through the rest:
.apache-steward.lock (committed) — the project's pin: install method + URL + ref + verification anchor;.apache-steward.local.lock (gitignored) — what this machine actually fetched + when;security, pr-management) to symlink in;.apache-steward-overrides/ (committed) for any local workflow modifications;post-checkout git hook so worktrees re-create runtime state automatically;After the skill finishes, you commit the small, focused diff — the bootstrap skill, the .gitignore entries, the two lock files (committed + gitignore exclusion for the local one), the overrides scaffold, the doc note — and you're done. Open a PR.
Future contributors who clone your repo just say “adopt apache-steward in this repo” (or invoke /setup-steward). The skill reads .apache-steward.lock (already committed) and re-installs to the same version your project pinned. No need to redo the manual recipe — the committed lock is the project's source-of-truth.
Every framework skill compares the gitignored .apache-steward.local.lock against the committed .apache-steward.lock at the top of its run. If they have drifted (project lead bumped the pin, or the local install is stale on a main-tracking adopter), the skill surfaces the gap and proposes /setup-steward upgrade. upgrade deletes the gitignored snapshot, re-installs per the committed pin, refreshes the gitignored symlinks, and reconciles any agentic overrides — see docs/setup/install-recipes.md and .claude/skills/setup-steward/upgrade.md for the full flow.
Three skill families ship in the framework. Pick whichever the adopter wants to use; symlinks for the picked families land in the adopter's skill directory.
| Family | Purpose | Detail |
|---|---|---|
| setup | Isolated agent setup, framework adoption + maintenance, shared-config sync. The prerequisite — at minimum the setup-steward skill itself runs out of this family. | 6 skills, docs/setup/ |
| security | 16-step security-issue handling lifecycle — from security@ import through CVE publication. Maintainer-only. | 8 skills, docs/security/ |
| pr-management | Maintainer-facing PR-queue management — triage, stats, deep code review. | 3 skills, docs/pr-management/ |
After the initial adoption, the same skill handles ongoing maintenance:
/setup-steward upgrade — refresh the snapshot to a newer framework version + reconcile any overrides against the new framework structure./setup-steward verify — read-only health check (snapshot intact, symlinks live, .gitignore correct, etc.)./setup-steward override <framework-skill> — open or scaffold an override file for a framework skill.MISSION.md — draft project-establishment proposal: motivation, scope, design commitments, initial PMC composition target.docs/setup/agentic-overrides.md — the contract between adopters who write overrides and framework skills that read them.docs/prerequisites.md — what a maintainer needs installed before invoking any framework skill (Claude Code, Gmail MCP, GitHub auth, browser, uv, etc.).AGENTS.md — agent instructions, placeholder convention, framework conventions.CONTRIBUTING.md — for framework contributors.