How to handle stuck reviews?

We have a process for bumping packages that are ready to be reviewed, and for packages that got stuck after passing the review.

But how to handle the case where the review gets stuck in between? In the case of this ([1]) PR, a review ended with a “changes requested” status. The requested changes were processed, and a re-review was requested, but there is no reaction. So the PR has still the “changes requested” status after months. What can be done when the reviewer is AWOL at the point where the requested changes have been implemented?



Perhaps a “needs re-review” thread could band-aid over it? Or guidelines on when its okay to ping reviewers again?

I’ve got a PR stuck in that state too, which is discouraging to say the least.

1 Like

The difference between a review and a re-review is pretty small, so I’d post it in the review needed thread. We cannot let unresponsive reviewers block a PR.

Edit: possibly post with a note saying that the changes requested has been addressed so that a new committer may think of dismissing the blocking review


I don’t think anyone should feel too cautious about asking for a re-review. Also if maintainers are overloaded, they should say so.

To communicate effectively I think often means communicating more in our case, but also communicating boundaries, and unsubscribing from issues to avoid overload.

Maybe we need to adjust and/or document our community “culture”?


Tried that (PRs ready for review _ - #3111 by gm6k), but this also doesn’t seem effective. The change request hasn’t been removed, there is just more confusion (the PR now contains at least three competing opinions on how a source code patch is supposed to be integrated), and it even attracted off-topic comments. It really doesn’t seem transparent at all what remaining changes (if any) would be needed for the PR to be considered mergeable.

1 Like