Sixty-one open issues and a release nobody can describe
A team of six maintains an open-source CLI. The repository has 61 open issues, nine of which are duplicates of two long-standing bugs; several are questions already answered in the README. The team uses a Projects board with columns for triage, in progress, and done, plus milestones named after releases. Last week a contributor opened PR #480 with the body Fixes #212, and it was merged into release/2.4. Issue #212 is still open. Leadership now wants a weekly triage routine and an accurate view of what shipped in 2.4.
1. Why did `Fixes #212` not close the issue, and what are the options now?
Read the worked answer
Closing keywords take effect when the pull request is merged into the repository's default branch. PR #480 merged into release/2.4, which is not the default branch, so the link was created but nothing was closed. The same rule applies to keywords in commit messages.
The reference itself is not lost: the issue timeline shows the cross-reference from the PR, so the history is intact even though the state is wrong.
Options, best first:
- Close #212 manually with a comment pointing at PR #480. Honest and immediate.
- If
release/2.4will merge back tomain, put the keyword in that merge pull request so it closes on the default-branch merge, keeping the automation honest. - Change the default branch, only if release branches really are the trunk, which is rarely true.
The process fix matters more than the one issue: release pull requests should list the issues they resolve, and triage should include a check for merged-but-unclosed work.
2. Design the weekly triage that gets 61 issues to a manageable state without burning the team of six.
Read the worked answer
Timebox it to one hour with two people, and make the output decisions rather than reading.
- Duplicates: close the nine with a comment naming the canonical issue and apply a
duplicatelabel. Do not delete them; they carry reproduction details and keep search working. - Questions answered in the README: convert to Discussions and close, so the issue tracker reflects work rather than support traffic.
- Incomplete reports: apply
needs-infoand close after fourteen days of silence. Issue forms that require version, command, and expected output cut this category structurally. - The rest: label by type, add to the Projects board, and set a milestone only when someone intends to ship it this cycle.
Automate the state changes: a Projects built-in workflow moves an item to Triage when opened and to Done when closed. Saved views per label then replace manual sorting.
3. Leadership wants an accurate list of what shipped in 2.4. What has to change about how milestones and the board are used?
Read the worked answer
The current setup can produce a plausible but wrong number, which is worse than no number.
Two separate things must be true. First, scope: a milestone should contain only issues and PRs the team actually committed to for that release, decided at planning, not discovered afterwards. Milestone progress is computed from open versus closed items, so anything merged into release/2.4 but left open drags the percentage down and hides real progress, which is exactly the #212 case.
Second, closure: closing keywords work only against the default branch, so release-branch merges need a documented manual close or a merge-back PR that carries the keywords. Add a pre-release checklist item that lists merged PRs into the release branch and verifies their issues are closed.
The board answers where work is; the milestone answers what is in scope. Keep them distinct, or the board's Done column becomes the release report and drifts from the milestone every time someone tidies the board.