Miss leading "Changes requested" status when a "Review Request" has been requested after applying changes.

[davola]

A given repo could have several PRs, on which their statuses can be "approved", "changes requested" or "Re-Review requested" (when changes are submitted and a new review is requested)

This third status where the PR has a pending review request is not reflected properly on the PR list status.

Consider this scenario or flow:

1. When a PR has a Review submitted with some changes pending, this is properly displayed on the PR list as "Changes Requested" as shown below
   

2. After the user applies those review changes requested, and submits the PR back for another review, the PR status keeps showing the wrong "Changes Requested" to the reviewer.
   You can check so in the image below. The filter for show only the PR that have a pending review for the user is set, but all the PR on that list appears to be on the status "Changes Requested", when it should say something like "Review Re-Requested" to reflect actual the actual status of it.
   

This will allow any reviewer to read the full list, without the need of applying any filter, and still be able to understanding which of the PRs there are ready for him to take action and start another review round.

Hope this make sense for anybody else, and thank you for your time on reading this! 🙏

[gtirloni]

Reviewers already get a notification in https://github.com/notifications

Maybe the UI could have a counter Changes requested (X) to indicate how many rounds of review+request have happened.

[davola]

Yeah, having the count would be awesome as well! 😀

The problem is not about notifications, but about being able to read the PR list, and quickly see which PR has changes requested, which is approved, and which is still waiting.

[olagjo]

Agreed with davola – in our organization we have some people who like to work based on notifications, and some people who like to work from the list. For those using the list and just seeing "Changes Requested" instead of "Review Required" or "Review re-requested", it instantly feels like the ball is with the author, while it is actually with the reviewer.

[patriciabetterimpact]

100% agree, this drives me crazy! Yea, i get a github notification, but that is not helpful, cos those don't even properly get pushed to teams in any sensible matter.

This list should show what the current status is.... If Changes are requested.... and then complete, and the committer has hit the Re-Request Review button... the status in this list should show Review Requested, or Re-Review Request, NOT changes requested. that is not where the PR is at, I should be able to see, at a glance of this list, which ones are ready for me to take another look at.

[chriskuech]

IMO this is a bug that breaks my PR review workflow. Solving this (compared to other accepted asks) seems relatively simple but would significantly improve the PR review workflow.

[patriciabetterimpact]

agreed 100%

[stianjensen]

Agreed. The current flow makes you very dependent on using notifications to know which of your opened PRs need action after a subsequent review or if they're still waiting. Or constantly opening all your open PRs to see their real status.

As a work-around I've now resorted in some of my repositories to run a GitHub actions script that dismisses existing reviews when re-requesting, since that then updates the status back to 'review required'.