patch list and dashboard do not show unresolved comment counts #63

New issue

Closed

opened 2026-08-11 10:58:15 +00:00 by a73x · 0 comments

a73x commented

2026-08-11 10:58:15 +00:00

(Migrated from git.a73x.sh)

28fc6751 implemented comment resolution: patch resolve/unresolve, patch diff --answers <comment>, grouping in patch show, --json, the timeline and a web marker.

Not implemented: unresolved counts in patch list and the dashboard.

That is the state a reviewer actually filters on. "Which patches have unanswered feedback" is the question that decides where to spend review time, and it is exactly what a list view is for — patch show answers it only one patch at a time, which means opening every patch to find the ones that need you.

Wanted: an unresolved count in patch list (and --json), the dashboard equivalent, and probably a filter for it alongside the existing status filters.

Note the display rule already settled: a resolution keeps the revision it was pinned to at write time, and a claim older than the current tip is surfaced as a hint (resolved by Alice at r1 — 2 revisions landed since) rather than as a state change. A list view needs to decide whether a stale claim counts as resolved for filtering purposes; patch show shows it as resolved-with-a-caveat, and a count cannot carry the caveat.

Migrated from git-collab issue 76c6cb58ad5b84ebe19de26910ff337578936fb0.

Original author: a73x dev@a73x.sh.

Close reason: merged in patch d452edbb

`28fc6751` implemented comment resolution: `patch resolve`/`unresolve`, `patch diff --answers <comment>`, grouping in `patch show`, `--json`, the timeline and a web marker. Not implemented: unresolved counts in `patch list` and the dashboard. That is the state a reviewer actually filters on. "Which patches have unanswered feedback" is the question that decides where to spend review time, and it is exactly what a list view is for — `patch show` answers it only one patch at a time, which means opening every patch to find the ones that need you. Wanted: an unresolved count in `patch list` (and `--json`), the dashboard equivalent, and probably a filter for it alongside the existing status filters. Note the display rule already settled: a resolution keeps the revision it was pinned to at write time, and a claim older than the current tip is surfaced as a hint (`resolved by Alice at r1 — 2 revisions landed since`) rather than as a state change. A list view needs to decide whether a stale claim counts as resolved for filtering purposes; `patch show` shows it as resolved-with-a-caveat, and a count cannot carry the caveat. --- Migrated from git-collab issue `76c6cb58ad5b84ebe19de26910ff337578936fb0`. Original author: a73x <dev@a73x.sh>. Close reason: merged in patch d452edbb