Memory hook: Track outcomes and flow, not just a pile of tickets.
Must remember
GitHub Projects organizes issues, pull requests and draft items using table, board and roadmap views. Views are different presentations of project data, with filters, sorting and grouping. Custom fields capture attributes such as priority, status or iteration; define them consistently so reports remain meaningful.
Labels classify repository issues/PRs. Milestones group work toward a release or objective with progress tracking. Assignees identify people responsible for work. These are related but not interchangeable: a label named release does not automatically behave like a milestone.
Built-in project workflows can update fields or archive items when conditions are met. Automation should reflect the team's real process; a merged PR may complete implementation while release or verification remains outstanding. Inspect the trigger and status meaning before treating a board column as delivery evidence.
Saved replies reduce repeated typing, but adapt them to the actual report. Issue forms/templates improve incoming information. Use project insights to examine flow and progress while recognizing what is not measured: closed-ticket counts do not directly prove customer value or quality.
Keep permissions, scope and audience in mind. A project can reference items with their own repository visibility restrictions. The presence of a project view does not grant access to all underlying private issues. Review stale work, blocked dependencies and unclear ownership regularly.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| See work by status | Board view grouped by a consistent status field. |
| Group issues for a planned release | Milestone. |
| Track a custom priority across repositories | Project field and filtered views. |
Traps
- Ticket count is not a reliable standalone productivity measure.
- Project access does not automatically reveal every private repository item.
Active recall
1. Table versus board versus roadmap?
Tabular fields, status-oriented cards and time-oriented planning views.
2. Label versus milestone?
Classification versus a grouped delivery objective/release.
3. Why define done clearly?
Automated status changes must match actual completion criteria.
4. What makes a saved reply useful?
A consistent starting point adapted to the specific issue.
5. Why inspect blocked work?
Blocked dependencies can explain delays better than raw closure counts.