Repository navigation
Reading the whole open queue for repeated work — and how often it's wrong #11192
Replies: 1 comment
|
After the duplicate finder I wanted to know what should happen to each open issue, so I've been building a sorter with five piles: look at it now, ready for an agent to pick up, the fix belongs upstream, ask the reporter, or park it. Plain code does the counting and lookups, and TypeSafe's Jev model makes the judgment calls. It's still read-only: it hasn't labelled, commented on or closed anything. I have three versions of it and no way yet to tell which is closest to right. For the duplicates I hand-read 83 pairs myself. This time I'd like help from people who know Omarchy better than I do, so I picked 80 open issues at random and put them on one page: https://parker-brown-family.github.io/fix-everything-triage/ Each issue is shown the way GitHub shows it, with four questions under it:
Edited 2026-09-25: the third question used to ask whether a maintainer should look at it "now", which could be read more than one way, and the fourth is new. Nobody had answered yet. "Can't tell" is always an answer, and it's more useful to me than a guess. Do as many as you like; one helps, and all 80 would be wonderful. When you're done, press send my labels: the page opens an issue on the fix-everything-triage repo with your answers filled in, and a check replies with what it read. Pasting the block as a reply here works too. If you'd rather hand this to your agent, that works. The repo's AGENTS.md tells it where the 80 issues are, what the answers mean and how to send them as an issue. Please say whether you or your agent answered, and which model; agent answers are counted apart from people's, since the question is whether the sorting agrees with people. Your answers stay in your browser until you send them, and the page loads nothing from outside itself. Once enough answers are in I'll post the comparison here, showing where the sorting agrees with you and where it doesn't. Source for the page: https://github.com/parker-brown-family/fix-everything-triage |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Plain english:
I built a script to scan for potential duplicate issues.
https://github.com/parker-brown-family/fix-everything-observatory/blob/main/tools/find-duplicates.py
The queue went from 63 new items a week in mid-July to over 1,100 a week now — 18x in two months — and 3,826 are open.. AND a community that is exploding means that FIX EVERYTHING is more fun and exciting than ever!
The FIX EVERYTHING OBSERVATORY IN ACTION:
screenrecording-2026-09-10_10-48-51.mp4
Explained:
omarchy toggle bar onhides the bar, andoffshows it — a two-line inversion inomarchy-toggle-bar. It is currently open sixteen times: seven issues and nineindependent patches, from fifteen different people, filed between 15 August and 7
September. None of them has merged. #7022 got there first.
I wanted to know how much of the queue looks like that, so I wrote something that reads
every open issue and pull request through
ghand groups the ones that are the same pieceof work. One Python file, standard library only. It is read-only:
--commandsprintsghcommands for you to read, and never runs them.
How wrong it is. I hand-read 83 of the pairs it grouped. Two patches doing the same
job held 13 times out of 30. Two reports of one bug, 15 out of 30. Where a patch declares
Fixes #N, that held 42 out of 42 — GitHub's own link is the one signal that never missed.So it is worth treating as triage, not as a verdict.
I am not proposing closing anything, and I have not commented on any of these tickets.
Useful? If not, no reply needed.
All reactions