Contributor-growth skill family
Scope —
organization: ASF· 🪶 ASF-specific. This family encodes Apache Software Foundation processes (the contributor-to-committer path) and assumes an ASF adopter profile by default. Non-ASF projects can still adopt it through the adapter/config layer, but it carries ASF assumptions the generic families do not.
Maintainer-facing skills that span the contributor-to-committer path: welcoming first-time contributors, keeping the issue backlog newcomer- ready, tracking contribution activity, comparing it with the project’s reference levels, measuring contributor sentiment, assembling nomination evidence, and walking nominators through post-vote onboarding. Nine skills cover the staged path from first contact through committer promotion.
Why a framework skill family? The contributor-to-committer path is one of the highest-leverage levers an open-source project has for long-term health — lowering onboarding friction and shortening the time from first PR to committer status keeps the contributor pipeline healthy. These skills were designed independently but cover a contiguous path; grouping them makes the adopter configuration and the evaluation story coherent.
Surface information, never rank
The skills that look at people — activity-sweep, calibrate, candidate-screen, contributor-to-committer and nomination — only surface information.
The decision about who is nominated, and when, is always made by PMC members.
- Never a ranking. No skill orders people by any measure, scores them against each other, or picks a “top” few. Every list of people is in alphabetical order of GitHub handle, compared case-insensitively.
- Never a verdict. No skill says or suggests whether someone is ready, close, or not ready to be nominated. Counts are shown next to the project’s reference levels as plain numbers, without a status, a band or a recommendation.
- Deliberately more, not fewer.
A list of likely candidates includes more people than the PMC would consider, on purpose, so that nobody is overlooked.
calibratesets its reference levels well below what the project has actually elected — by default three quarters of it (calibration_relaxation,0.75) — to make that true. Appearing on a list means only that someone’s details are worth a look. - A report is a list and a summary. A report lists the people it covers, alphabetically, each linked to their details, followed by a paragraph or two summarising what was found. The summary describes the findings; it does not judge or recommend anyone.
Every brief and report these skills produce says this at the top.
Install & first runs
Install just this family — one plugin, 9 skills. The path-to-committer track.
Once you have added the marketplace:
/plugin install magpie-contributor-growth@apache-magpieNew to Magpie? The quick start walks the whole path in
one place — install, the first /magpie-setup run, and a recording of it
happening — plus the other agents and the secure-isolation setup to run next.
Before the first run
Illustrative — the real run derives more and asks better. What is true is the shape: it runs itself, it writes only your personal layer, and it stages nothing.
Every skill here resolves project-specific values from the adopter’s
<project-config>/ directory — which is
your personal layer first — .apache-magpie-local/ (gitignored) in a
project that adopted Magpie, <git-common-dir>/apache-magpie/ in one
that did not — then .apache-magpie-overrides/ (committed, the project’s).
For yourself: /magpie-setup config scaffolds and fills these locally.
Nothing is staged, nothing is committed, and it works on a repository that
has never adopted Magpie.
This configuration stays personal. /magpie-setup adopt never
promotes or scaffolds it into .apache-magpie-overrides/: committed
thresholds would tell every contributor how to game them.
Required. Without these a skill would act on a guess, so it stops and says which file is missing.
| File | What it carries | Read by |
|---|---|---|
committer-onboarding-config.md |
Capability-flag vocabulary for committer intake and governance models (icla/dco/no-cla; asf-pmc/github-codeowners/maintainer-roster). |
committer-onboarding |
committer-readiness.md |
The project’s declared committer and PMC thresholds — what a contributor’s activity is measured against. | calibrate, candidate-screen, contributor-to-committer |
contributor-nomination-config.md |
Nomination-brief thresholds and assessment window. | calibrate, candidate-screen, nomination |
contributor-sentiment-config.md |
Signal thresholds for the sentiment gate. Every key has a default. | sentiment |
onboarding-concierge-config.md |
The path a new contributor is walked through, and who owns each step. | onboarding-concierge |
privacy-llm.md |
Which model tier may see which class of content, for projects routing foundation-private information away from third-party models. | calibrate |
project.md |
Project manifest. Identity, repositories, mailing lists, tools enabled, CVE tooling, GitHub project-board + issue-template field declarations. The single file every skill reads to resolve project-scoped references. | activity-sweep, calibrate, candidate-screen, committer-onboarding, contributor-to-committer, identity-map, nomination, onboarding-concierge, sentiment |
Optional. Each has a documented fallback; absent, the skill still runs.
| File | What it carries | Read by |
|---|---|---|
contributor-identities.md |
The project’s community channels, and confirmed mappings from each contributor’s GitHub handle to their Slack, Discord, mailing-list, and social-media handles. Written by contributor-identity-map after a maintainer confirms each one. |
committer-onboarding, identity-map |
issue-tracker-config.md |
Tracker URL, project key, auth model, default query templates. | activity-sweep, calibrate, contributor-to-committer, nomination, sentiment |
pmc-roster.md |
Who is binding. Read wherever a vote is counted or a PMC-only action is gated. | candidate-screen, nomination |
Why the configuration is personal
This family is personal-recommended and not adoptable by default.
Install it for yourself — user scope, or install-only in this repository — on the machine of each maintainer who runs these skills.
/magpie-setup adopt leaves it out of the committed floor unless a maintainer explicitly insists and accepts the risk below, and records that acceptance in .apache-magpie.lock.
The reason is gaming. Committer thresholds, nomination criteria, calibration floors, sentiment caps and the identity map are the project’s private judgement about people. Committed to the repository, they become a public checklist: a contributor can point at a threshold and demand a nomination, and every later edit to it becomes a negotiation rather than a decision.
So the five files this family adds — committer-onboarding-config.md, committer-readiness.md, contributor-identities.md, contributor-nomination-config.md and contributor-sentiment-config.md — always live in your personal layer, even in a project that has adopted Magpie and even when the family itself is in the floor:
<git-common-dir>/apache-magpie/ when Magpie is only installed, .apache-magpie-local/ when the project has adopted it.
Never commit them to .apache-magpie-overrides/;
adopt does not promote or scaffold them there, and the skill validator warns when it finds one.
contributor-calibrate writes its floors to the personal layer and never offers the committed one.
Maintainers who want the same numbers share them the way they share the deliberation itself, on the private list.
Try these first
Illustrative shapes, not real transcripts — your output will differ. Nothing below sends, merges, or posts anything without you confirming it.
Sweep recent contributor activity.
/magpie-contributor-growth:activity-sweep
Draft a nomination brief.
/magpie-contributor-growth:nomination
Onboard a new committer.
/magpie-contributor-growth:committer-onboarding
Stage coverage
| Stage | Skill | What it does |
|---|---|---|
| First contact | mentoring-welcome |
Drafts an orientation comment for a first-time contributor on a newly opened issue or PR; detects first-time authorship via the GitHub author_association field and skips repeat contributors. |
| Issue on-ramp | good-first-issue-author |
Drafts one net-new good first issue from a supplied gap or small task; a suitability gate and R1–R9 readiness checklist gate the draft; waits for maintainer confirmation before filing via gh. |
| Backlog curation | good-first-issue-sweep |
Sweeps the open issue backlog for existing issues that could be labelled as good first issues; scores each against the G1–G7 suitability rubric; classifies as READY / NEAR-MISS / SKIP and proposes labels after explicit maintainer confirmation. |
| Activity tracking | contributor-activity-sweep |
Produces a read-only GitHub activity card (PRs authored, code reviews, issues, comments) over a configurable window. |
| Calibration | contributor-calibrate |
Derives committer and PMC reference levels from the project’s own past nomination decisions on the private list, deliberately relaxed well below what the project elected; proposes a config diff holding numbers only, with nothing about any nominee leaving the session. |
| Candidate screening | contributor-candidate-screen |
Surfaces details about likely committer and PMC candidates — deliberately more people than the PMC would consider — and writes a report to a repository the GitHub API reports as private, after the maintainer has read it: an alphabetical list linked to each person’s details, and a paragraph or two summarising the findings. Never a ranking, never a verdict. |
| Activity vs. reference | contributor-to-committer |
Shows a contributor’s activity next to the project’s committer or PMC reference levels, as plain numbers with the difference, and a short factual summary. No status, band, or readiness verdict. Read-only; never opens a nomination thread. |
| Identity mapping | contributor-identity-map |
Maps any contributor’s GitHub handle to their Slack, Discord, Matrix, mailing-list, and social-media handles; infers from the sources the session can reach and records only the mappings a maintainer confirms. Used by committer-onboarding and contributor-nomination. |
| Nomination brief | contributor-nomination |
Assembles evidence for a committer or PMC discussion: activity breadth, consistency, vendor-neutrality context, and factual narrative prose. Never rates the contributor or says whether they are ready. Read-only; never posts to any list. |
| Sentiment analysis | contributor-sentiment |
Analyse contributor sentiment signals (issue tone, PR abandonment, response-time frustration) to surface early-warning indicators of contributor disengagement. Read-only. |
| Onboarding concierge | onboarding-concierge |
Interactive first-session guide for new contributors: walks through repo setup, points to good first issues, introduces project conventions and communication channels. |
| Post-vote onboarding | committer-onboarding |
Walks the nominator through ICLA check, account provisioning, permissions grant, and the welcome announcement for committer and PMC promotions at ASF TLPs and podlings. |
Every stage is read-only on governance artefacts or propose-before-post: no skill modifies a roster, posts an announcement, or files an issue without explicit maintainer confirmation.
Skills
| Skill | Mode | Status |
|---|---|---|
mentoring-welcome |
Mentoring | experimental |
good-first-issue-author |
Mentoring | experimental |
good-first-issue-sweep |
Mentoring | experimental |
contributor-sentiment |
Triage | experimental |
onboarding-concierge |
Mentoring | experimental |
contributor-activity-sweep |
Triage | experimental |
contributor-identity-map |
Triage | experimental |
contributor-to-committer |
Mentoring | experimental |
contributor-nomination |
Triage | experimental |
contributor-calibrate |
Triage | experimental |
contributor-candidate-screen |
Triage | experimental |
committer-onboarding |
Triage | experimental |
All twelve skills are experimental; no adopter has run the full
contributor-to-committer path under evaluation conditions yet.
Family boundary
This family sits alongside two overlapping skill families:
docs/mentoring/README.md— the Agentic Mentoring mode spec and family overview.mentoring-welcome,good-first-issue-author, andgood-first-issue-sweepcarrymode: Mentoringand are also listed in that spec. The families cross-reference each other; a later maturity review may clarify the boundary or merge the two into one.docs/issue-management/README.md— general-issue triage and fix workflow. The contributor-growth family reads GitHub activity data about contributors, not issue content; the two families use different query surfaces and produce different artefacts (activity cards and nomination briefs vs. issue disposition proposals).
Skills in this family propose every state-changing action for human
sign-off. committer-onboarding emits paste-ready command recipes the
nominator executes as themselves; no skill submits an ICLA form, invites
an account, or modifies repository permissions without the nominator’s
direct action.
Status
Experimental. All eleven skills are on main with eval suites; no adopter has run the full contributor-to-committer path end-to-end under evaluation conditions.
Known deferred items (each pending a spec-RFC pass that enumerates per-project policy knobs before a skill can safely propose anything):
- PMC-member nomination — vote mechanics, quorum rules, and
post-vote steps differ from committer promotion and warrant a
separate capability-flag variant of
committer-onboardingor a standalone skill. - Emeritus / inactive-committer handling and contributor offboarding — these involve project-level governance decisions (roster policy, access removal, farewell communication norms) that need per-project configuration.
Cross-references
docs/modes.md§ Triage — mode taxonomy the three Agentic Triage-mode family skills declare against.docs/modes.md§ Mentoring — mode taxonomy the three Agentic Mentoring-mode family skills declare against.docs/mentoring/README.md— the Agentic Mentoring mode family overview, which cross-referencesmentoring-welcome,good-first-issue-author, andgood-first-issue-sweep.projects/_template/README.md— adopter scaffold index, with a purpose line for every file the table under Before the first run links.docs/setup/agentic-overrides.md— the override mechanism every skill in this family supports.