While the system is cool, it can be quite overwhelming as there are a lot of done entries. Undone work might vanish, because loads of done work lie between that reply and the bottom of the thread.
Something like a queue, where entries can get added in a similar fashion like the discourse thread, but then get hidden/removed once done would be better.
Perhaps it could be as simple as writing a plugin that checks periodically if all PRs mentioned in a reply are merged, and then automatically makes that reply vanish. Or moves the reply to another thread, therefore acting like a queue that allows state changes.
Other ideas also useful to consider:
Using GitHub projects as queues
Using standalone software for queues, that has been built specifically for that purpose
Using a bot that handles the queues (I think there was something like that, the marvin bot, but it hasn’t been widely adopted)
Another way to see the problem is considering the open pull requests the queue.
The proposal is that after someone reviews a PR there can be two actions only: merge or close-with-comment (saying what needs to be improved before reopening the PR). This way the pull requests that have not been reviewed remain open, and thus the open pull requests are the queue. The pull requests that were reviewed are merged or closed, and therefore nobody has to circle back to them. We’d only have to look at the open ones
The eventual goal is to make it “really easy for a committer to click merge”. Using diff information from the base branch to the PR, we can conclude more things like runtime closure differences, package size differences, new regressions, fixed builds, new packages, removed packages. The page of information should anwser, “does this diff match the intended effects”. And try to minimize “number of clicks”, so that a reviewer can quickly iterate on many PRs; this would include being able to comment, review, merge, or close a PR like you would in the normal github workflow.
It’s pretty common to have some iteration, I don’t like the idea of having a final conclusion because someone forgot to format a commit message correctly.
people can edit the commit message and then re-open the same PR, so it re-enters the queue and someone can review it
I agree having the tooling would be nice, at the same time we don’t have it, and my proposal could be a simple-to-implement mechanism that solves the problem
I’m open to more ideas of course! whatever attacks the root of the problem is nice
GitHub allows filtering by review status (and more), which should already cover this. Closing issues sends the wrong signal - after all a reviewer offers suggestions and is not neccessarily right.
If anything, there’s value in coming up with clever ideas to filter the current list of issues, or add additional value through automation (i.e. @jonringer’s ideas). Being able to quickly identify things like trivial PRs, or new contributor’s PRs might prove useful.
The only use case I see for closing unresolved PRs would be auto closing if an author goes AWOL while the PR is reviewed with status changes requested. But even then, being able to simply filter them out might make more sense.
This is a little tangential, but GH is slowly but steadily plodding ahead with their issues/project beta which may eventually yield some new levers on that side of things. I described this previously in the post linked below (though I didn’t realize I was quoting sort numbers and not issue IDs):
I think the issues I had in mind as being most helpful were:
I don’t really want to encourage waiting on GH, since the wait for the features we need might be unbounded. But seeing their steady progress (issues Archives - The GitHub Blog gives a more digestible view into their cadence, I guess) has given me some hope that it’s getting “real” enough that it’s worth thinking about how we could put it to use (and weighing it against alternatives that could work in the here and now).