Enable and adopt usage of GitHub Projects

[don-petry]

Currently, this org is using Discussions for ideas and Issues for implementation. Issues provide a very limited/simplistic approach to defining and managing the delivery of complex work items which require many distinct steps, PR's and quality gates.

Evaluate GitHub Projects to understand how our work planning and delivery could benefit from this capability.

https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

[don-petry]

Analysis: pilot scope and bootstrap

Spent some time on this with current-state evidence from the org. Posting the analysis here so it lives in the artifact, not just in chat.

Why the premise holds

Issue volume across the org (~390 open across 8 repos) hides three different shapes of work in one queue:

Shape	Examples	What it needs
Automation noise	[Fleet Monitor] — ci.yml, Compliance: unpinned-actions-*, Trigger diagnostic …, daily Org Status	Just to not drown out the rest
Recurring programs	Compliance blitzes (5/20: 27+ issues closed in a day; 5/23: 8 PRs + 2 enhancements across .github and .github-private), Fleet Monitor health checks	Cross-repo roll-up
Initiatives	Agent Shield v2 (#269), Self-Healing Compliance (#270), in-Claude model fallback (PR #380), Auto-rebase vs. Merge Queue eval (#358)	Status beyond open/closed; a roadmap

Labels (dev-lead, claude, compliance-audit, health-check, fleet-tracker, daily-report) are currently doing the work that Project fields + Status are designed for. They've stretched as far as they can.

What Projects buys, specifically:

1. A cross-repo plane. Today the compliance blitzes only exist as auto-memory notes — there's no GitHub artifact tying their PRs/issues together.
2. Stage tracking beyond open/closed. Initiatives sit in Ideas with no way to see "specced" vs. "in dev" vs. "shipped" without reading every comment.
3. A home for Issue Fields (Enable and define Issue fields #364). The two features were designed to be used together — Fields without a Project view are just metadata.
4. Ergonomics for the agent fleet. dev-lead, claude, ci-failure-analyst, etc. navigate by label/title heuristics today. Typed Project fields give them stable, machine-readable state.

What it does not buy: less work overall (taxonomy + automations are real overhead), a replacement for Discussions (still good for incubation), or PR quality gates (those stay in rulesets).

Pilot proposal: one org-level project, "Initiatives"

Not three boards. Not per-repo. One.

Fields:

• Status (single-select): Inbox → Specced → In Dev → In Review → Deployed → Verified → Won't do
• Initiative (single-select): Compliance Blitz, Compliance program, Fleet Monitor, Agent Shield, Auto-rebase, Self-healing, Model fallback, Tooling, Ad hoc
• Type: Feature / Spike / Fix / Infra / Security / Docs
• Priority: P0 / P1 / P2 / P3
• Owner-agent: dev-lead / claude / coderabbit / copilot / human
• Target date (date, optional)

Membership rules (the noise gate):

• Every Ideas-category discussion → draft item on creation (Status=Inbox)
• Every issue labeled dev-lead and not labeled compliance-audit / health-check / fleet-tracker / daily-report → auto-add
• Linked PRs → auto-add

Views (day one):

• Roadmap — table grouped by Initiative, then Status
• In flight — board by Status, filter out Inbox/Verified/Won't do
• Ideation — table of Inbox items linked to discussions
• By agent — board grouped by Owner-agent

Backfill on launch

• This discussion (Enable and adopt usage of GitHub Projects #386) — adopt GitHub Projects (see "Bootstrap" below)
• Discussion Enable and define Issue fields #364 — Issue fields
• Discussion 💡 Agent Shield v2: CI Pipeline Prompt Injection Sentinel #269 — Agent Shield v2
• Discussion 💡 Automated Compliance Self-Healing Pipeline #270 — Self-Healing Compliance pipeline
• Discussion Auto-Rebase Workflow vs. GitHub Merge Queue #358 — Auto-rebase vs. Merge Queue evaluation
• PR chore(deps): Bump gitleaks/gitleaks-action from 2.3.9 to 3.0.0 #380 — in-Claude model fallback
• Initiative: Compliance Blitz — covering the 5/20 and 5/23 blitzes plus the underlying program. Backfill the closed work as Verified items so the board reflects actual history, not just open work. Currently invisible outside auto-memory; this is the highest-value historical record to get into the Project.
• The 4 most recent open 💡 ideation discussions (💡 Unified Agent Cost Observability Dashboard #338–💡 Intelligent CI Failure-to-Agent Router #342 range), Status=Inbox

Bootstrap — yes, this effort itself becomes the first Project item

Cleanest order:

1. Create the project + fields manually
2. Add this discussion (Enable and adopt usage of GitHub Projects #386) as the first draft item: Initiative=Tooling, Type=Infra, Status=Specced, Owner=human
3. Spec out the work as a tracking issue in .github, link it to the project item, advance Status as it lands
4. Ship the auto-add workflow as the second item, again tracked on the board

Two reasons this is the right move:

• Dogfood validation. If the workflow of "discussion → draft item → spec → issue → PR → Verified" is awkward when applied to the project itself, that's the most valuable feedback available before onboarding real work.
• Audit trail. Six months from now, "why did we adopt Projects" should be answerable from the Project, not from memory.

Deferred (intentionally)

• Program boards for Compliance and Fleet Monitor. Compliance Blitz lives in Initiatives as an Initiative bucket for now. If volume justifies a dedicated board after 30 days, split it out — but day one, one board.
• Issue Fields (Enable and define Issue fields #364) rollout — wait until Project field schema has stabilized (~30 days), then mirror the same schema as Issue Fields so issues carry the metadata independent of project membership.
• Replacing label-based daily report (Org Status — 2026-06-03 #385) with Project-state report. Worth doing, but only after auto-add is reliable.

Risks worth flagging

• Projects v2 API is GraphQL-only with a separate read:project / project token scope — needs token + workflow permission setup before any automation lands.
• Renaming/removing single-select options on a populated project is painful — lock the schema before auto-add ships.
• The noise filter is load-bearing. If compliance-audit / health-check / fleet-tracker / daily-report issues leak into the Initiatives project, it just rebuilds gh issue list with extra steps.

Suggested next steps

1. Create project "Initiatives" with the 6 fields above
2. Backfill the items listed (including Compliance Blitz history)
3. Add Enable and adopt usage of GitHub Projects #386 as item 1, Status=Specced
4. Spec out the auto-add workflow (token scopes, label filters, draft-from-discussion logic) as item 2
5. Run for 30 days. Decision point: keep / add program boards / abandon

[don-petry]

Update — forward links to the implementation work this discussion seeded:

• Project (live): https://github.com/orgs/petry-projects/projects/1 — "Initiatives", pre-loaded with 15 backfill items (linked PRs + draft items for ideation discussions + Compliance Blitz history)
• Tracking issue: Adopt GitHub Projects: org-level Initiatives pilot #387 — scope, acceptance criteria, deferred items, and what's required on top of the merge (org secrets, manual view setup)
• Implementation PR: feat(workflows): add Initiatives project auto-add workflow #388 — the add-to-project.yml workflow with the noise gate and discussion reconciliation, plus the bats test suite, currently undergoing final CI

The pilot runs 30 days from merge. Decision point at the end: keep, expand (program boards for Compliance and Fleet Monitor), or roll back.