Issue And Project Tracking

---
name: issue-and-project-tracking
description: Structure issues, labels, and boards so the tracker reflects reality and answers what is being worked on. Use when the backlog has grown beyond what anyone reads.
---

# Issue and project tracking

A tracker earns its keep by answering two questions: what is being
worked on, and what is waiting. Most trackers answer neither because
everything is open, nothing is prioritised, and labels multiplied
without discipline.

## Method

1. **Use templates to get what you need up front.** Reproduction steps,
   version, and expected behaviour asked at creation, which saves the
   round trip that most reports need (see issue-triage).
2. **Keep labels few and decision-bearing.** Labels that change what
   happens next earn their place; taxonomies for their own sake do not.
3. **Distinguish the backlog from the active board.** Everything is not
   in progress, and a board showing forty in-flight items is showing
   nothing.
4. **Close aggressively and kindly.** Stale, out of scope, and will not
   fix are outcomes, and a tracker where nothing closes is one nobody
   trusts.
5. **Link issues to the work.** Pull requests referencing issues close
   them automatically and create the trail from request to change.
6. **Use milestones for genuine deadlines only.** A milestone that slips
   repeatedly teaches everyone milestones are decorative.
7. **Review the board on a cadence with decisions.** Items that have not
   moved need a decision rather than another week of visibility (see
   agent-accountability-loop).

## Boundaries

A tracker records work; it does not prioritise it, which needs judgement
about value (see prioritization-frameworks). Public trackers are
visible to competitors and customers, which shapes what belongs in them.
Process weight should match team size, since heavy process on a small
team is pure overhead.