|
1 | 1 | --- |
2 | 2 | name: contributor-pipeline-gardening |
3 | 3 | description: >- |
4 | | - Daily maintenance of the contributor issue pipeline for JSONbored/gittensory (renaming to |
5 | | - loopover) — closing issues that are already done but not marked so, and topping up the |
6 | | - contributor-available backlog with well-scoped new issues. Invoke for "run the daily issue |
7 | | - gardening", "audit open issues for stale/complete ones", "generate new contributor issues", |
8 | | - or any recurring/scheduled run of this process. `reference.md` (next to this file) has the |
9 | | - exhaustive label/milestone/template detail — read it before doing real work, not just this file. |
| 4 | + Maintenance of the contributor issue pipeline for JSONbored/gittensory (renamed to loopover) — |
| 5 | + closing issues that are already done but not marked so, and keeping the contributor-available |
| 6 | + backlog at its 50-100+ steady-state floor with well-scoped new issues. Runs every ~8h via the |
| 7 | + scheduled task (raised from daily on 2026-07-15 so the floor is maintained continuously, not |
| 8 | + caught up once a day). Invoke for "run the issue gardening", "audit open issues for |
| 9 | + stale/complete ones", "generate new contributor issues", or any recurring/scheduled run of this |
| 10 | + process. `reference.md` (next to this file) has the exhaustive label/milestone/template detail — |
| 11 | + read it before doing real work, not just this file. |
10 | 12 | --- |
11 | 13 |
|
12 | 14 | # Contributor pipeline gardening — gittensory / loopover |
@@ -46,17 +48,19 @@ assume it keeps happening, don't assume today's backlog is clean. |
46 | 48 |
|
47 | 49 | ## Pass 2 — backlog top-up |
48 | 50 |
|
49 | | -**Target: keep this repo's own contributor-available count (unassigned, no `maintainer-only`, carries a `gittensor:*` label) at 50-100+, independently of metagraphed's count** — this is NOT a combined/shared pool across the two repos; each repo needs its own 50-100+ on its own goals. Compute it fresh: `gh issue list --state open --limit 1000 --json number,labels,assignees` and filter. |
| 51 | +**Target: keep this repo's own contributor-available count (unassigned, no `maintainer-only`, carries a `gittensor:*` label) at 50-100+, AT ALL TIMES, independently of metagraphed's count** — this is a steady-state floor to maintain continuously, not a one-time catch-up, and NOT a combined/shared pool across the two repos; each repo needs its own 50-100+ on its own goals. Compute it fresh: `gh issue list --state open --limit 1000 --json number,labels,assignees` and filter. |
| 52 | + |
| 53 | +**If the count is meaningfully under floor, keep sourcing issues until it clears (or a pass genuinely turns up no more real, non-duplicate gaps) — don't stop at a modest first batch.** "Quality over volume" (point 6 below) means don't pad with weak/duplicate/vague issues, it does not mean stopping early once *a* well-scoped batch is filed. When under floor: extend an already-proven, well-precedented vein first if one exists (e.g. a REST/GraphQL/MCP parity sweep with many remaining candidates — the fastest path to more verified, non-padded issues), then dispatch parallel subsystem-audit agents across distinct areas of the codebase once that's exhausted. |
50 | 54 |
|
51 | 55 | 1. **Read `reference.md`'s "what's safe to unleash" framework first.** The single most common mistake is generating architecture/business-decision issues (hosted multi-tenant SaaS design, billing, SLAs, pricing) that must stay `maintainer-only` — this repo has ~90 such issues already correctly gated and the automation must not erode that boundary. Concrete engineering work with a clear existing precedent to follow is the target; open-ended product/business decisions are not. |
52 | 56 | 2. Pick real gaps to scope from, in priority order: |
53 | 57 | - Existing open epics/roadmap issues in this repo that don't yet have enough decomposed child issues to be actionable (e.g. `ORB - Long Term Features & Improvements`, the review-comment-redesign family, any epic whose own body describes scope with no filed sub-issues yet). |
54 | 58 | - Genuine gaps found by reading the current codebase against a shipped feature's own stated acceptance criteria (the same technique Pass 1 uses to verify closure — used here in reverse, to find what's NOT yet done). |
55 | 59 | - AMS selfhost hardening is a named standing priority — see `reference.md`. The unified AMS+ORB selfhost harness is now scoped and issue-backed (#5996, epic #6012) as of 2026-07-15 — check its sub-issues' completion state before assuming this still needs fresh scoping. |
56 | | -3. Every new issue gets: the correct existing milestone (creating a new one requires a genuinely-unfitting body of work AND is a much higher bar than it sounds — see `reference.md`'s milestone-discipline note; when in doubt, fold into the closest existing bucket and say so rather than create one), a `gittensor:bug` (0.05x), `gittensor:feature` (0.25x), or `gittensor:priority` (1.5x, reserved for mission-critical/time-sensitive work only — this repo uses it sparingly, unlike metagraphed's looser convention, see `reference.md`) label, plus `help wanted` (the maintainer confirmed this stays as a visibility signal alongside the points label, not a replacement for one). |
| 60 | +3. **Every new issue gets a real milestone — no issue ships unmilestoned.** Default to the correct existing milestone (see `reference.md`'s milestone taxonomy). Creating a new one requires a genuinely-unfitting body of work AND is a much higher bar than it sounds — see `reference.md`'s milestone-discipline note; when in doubt, fold into the closest existing bucket and say so. A new milestone is justified when nothing existing fits AND the work is either a real major initiative or a recurring category that will keep needing a home (e.g. `Miner Wave 4.5 — AMS Hardening Round 2`, created 2026-07-15 for the recurring post-Wave-4 gap-audit rounds this skill files each run) — a one-off oddity alone isn't enough. Also apply a `gittensor:bug` (0.05x), `gittensor:feature` (0.25x), or `gittensor:priority` (1.5x, reserved for mission-critical/time-sensitive work only — this repo uses it sparingly, unlike metagraphed's looser convention, see `reference.md`) label, plus `help wanted` (the maintainer confirmed this stays as a visibility signal alongside the points label, not a replacement for one). |
57 | 61 | 4. Every new issue body follows the template in `reference.md` — Context, Requirements, Deliverables, Test Coverage Requirements (this repo's Codecov patch gate is 99%+, hard — every new issue implicitly inherits this unless it's `apps/**`-only UI work), Expected Outcome. No "left to interpretation" scope — the maintainer's own stated preference is that thin/ambiguous issue bodies are worse than fewer, complete ones. **The review gate only enforces what the issue text explicitly says** — see `reference.md`'s dedicated section on this; any deliverable with a file-type/path/format constraint (docs as website pages vs. markdown, native relationships vs. checklists, etc.) needs that constraint stated as an explicit, standalone rule, not left implied by Context. |
58 | | -5. Link relationships using GitHub's native features, not prose: `addSubIssue` to attach a new issue under its parent epic, `addBlockedBy` when an issue genuinely cannot start before another lands. Only use these where a real dependency exists — don't chain issues into an artificial order to look organized. |
59 | | -6. Quality over the number. If a scan doesn't turn up enough genuinely well-scoped, non-redundant, correctly-boundaried issues in this repo alone to keep its own count in the 50-100+ range on a given day, file fewer rather than pad with weak ones — note the shortfall in the daily digest instead. |
| 62 | +5. **Check every new batch for real relationships, then link them with GitHub's native features, not prose or a checklist:** `addSubIssue` to attach a new issue under its parent epic, `addBlockedBy` when an issue genuinely cannot start before another lands. The check itself is the discipline — most independent bug-fix/feature-parity issues (e.g. a batch of REST/GraphQL-mirror additions) genuinely have no dependency on each other, and forcing a link where none exists is worse than no link. Only connect issues where a contributor would actually be blocked or misled by working them out of order. |
| 63 | +6. Quality over the number in what gets filed — don't pad with weak, duplicate, or vaguely-scoped issues just to hit a count. This is NOT license to stop early: if the repo is meaningfully under the 50-100 floor, keep sourcing real, well-scoped issues (see the "if under floor" note above) until it clears or a pass genuinely turns up nothing left to scope — only then note a shortfall in the digest. |
60 | 64 |
|
61 | 65 | ## Daily digest |
62 | 66 |
|
|
0 commit comments