Amey-Thakur 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
- 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).
- Keep labels few and decision-bearing. Labels that change what happens next earn their place; taxonomies for their own sake do not.
- Distinguish the backlog from the active board. Everything is not in progress, and a board showing forty in-flight items is showing nothing.
- Close aggressively and kindly. Stale, out of scope, and will not fix are outcomes, and a tracker where nothing closes is one nobody trusts.
- Link issues to the work. Pull requests referencing issues close them automatically and create the trail from request to change.
- Use milestones for genuine deadlines only. A milestone that slips repeatedly teaches everyone milestones are decorative.
- 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.