Merge request reviewers
Dedicated "reviewers" section for merge requests: MR Form
Requesting a code review is an important part of contributing code. However, deciding who should review your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and reviewers makes it hard for others to determine who's doing what on a merge request.
GitLab 13.5 introduces merge request "reviewers", which easily allow authors to request a review as well as see the status of the review. By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request. This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review form a peer.
Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center. You can follow along in the merge request reviewer assignment epic for more details.
When making a contribution via a merge request, once we find a reviewer we assign them to the MR via the "assignee" field. Once they are done with the first review, they may assign the author back as "assignee" for updates. The cycle repeats as the review goes back and forth. This presents a couple of problems:
- Author must go through MR history to find the original reviewer
- Unnecessary assigning back and forth is required from everyone
- Peers who are coming on to assist cannot easily find relevant players for this merge request
- New reviewers can't know if a peer has already reviewed and may pile on, leading to duplicate efforts
- Author does not know if a reviewer has reviewed but not approved and more work is needed from them
- Rachel (Release Manager)
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Presley (Product Designer)
- Devon (DevOps Engineer)
- Simone (Software Engineer in Test)
Provide a mechanism which:
- Allows MR author to explicitly define Reviewers (not assignees) (this issue)
A notification is sent to reviewers when they are selected/unselected (this issue)
- Reviewers also get a To-do (this issue)
- (out of scope) In the MR sidebar, show a list of reviewers #237921 (closed)
- (out of scope) In the MR list, show the reviewers next to the assignees #237922 (closed)
|MR form||MR sidebar #237921 (closed)||Select reviewers #237921 (closed)||MR list #237922 (closed)|
|The “Reviewers” field is placed below the “Assignee” field and behaves just like the Assignees.||Like the MR form, in the sidebar the Reviewers field is also below Assignees and function exactly like the latter.||When selecting Reviewers, the dropdown header reads
||The reviewers are also visible in the MR list, after the assignees. The tooltip reads
|— out of scope||— out of scope||— out of scope|
Alining with our assignee limits, Core will be limited to one reviewer, Starter+ will support multiple.
What does success look like, and how can we measure that?
We must be able to determine the percentage of MRs that are using this field in order to track its usage
Links / references
Please note both this issue and #237921 (closed) share the dropdown.