Show list of code reviews on the merge request
Problem to solve
As a prospective reviewer/approver, I want to know if a relevant peer has already reviewed the merge request, so that I don't pile on or use my own time inefficiently. If a relevant peer has already performed a review but has not approved the merge request, this is very important information.
Currently the only way I can answer these questions is to skim through the entire merge request and try to spot the people I know. This works fine in a small team, but as teams grow and their are hundreds/thousands of engineers this doesn't scale. It is also not inclusive of new team members who simply learnt who should review what.
Further details
Currently merge requests have the concept of approvals and resolvable discussions – these seem like related concepts and can probably be reused and avoid formally requiring someone to submit a review.
This issue should also provide the some direction towards filtering conversations/discussions, so that as a reviewer I can re-review my feedback and how it was addressed.
Proposal
From the perspective of an eligible approver, a merge request can be:
-
unreviewed(default): I have not looked at it, I have not left a comment, I have not approved it -
reviewed: I have reviewed it, I have left one or more comments, and I have not approved it -
approved: I have reviewed it, I have left one or more comments, and I have approved it
We already show who has approved a merge request. Using the states above we should also show how has reviewed the merge request.
It would also be nice to see from who the majority of unresolved feedback is from – is this merge request being obstructed by incomplete documentation, or feedback from a senior engineer who unresolved feedback about the current implementation.
Questions:
- As the author, if I ask for feedback from an approver on something that I know if a problem, how will that appear? Since they reviewer is not the author of the resolvable discussion thread, how do we attribute it? Maybe this does not need to be resolved in this iteration, but it bears consideration.
| Mockup: reviews with unresolved feedback | Mockup: count of unresolved feedback |
|---|---|
 |
 |
Documentation
What does success look like, and how can we measure that?
This is a quality of life improvement that in combination with https://gitlab.com/gitlab-org/gitlab-ce/issues/58721 should reduce the average amount of time reviewers spend per session looking at the merge request because they are able to find their information faster. The number of sessions should be relatively constant.
This should support continued growth and adoption of merge requests by existing customers.