Increase efficiency of managing reviews and addressing feedback: Review panel
We want to _increase the efficiency of understanding context of reviews by managing unresolved comments_. We have a hypothesis that by using the review panel https://gitlab.com/gitlab-org/gitlab/-/issues/474799, users will be able to find unresolved threads of a review faster. Currently when a review is performed there's no grouping or indication in the UI of all of the feedback that was left as part of the review. This makes it challenging to understand the feedback during each round and which comments were left at which point in time during the review. Comments of a review can appear in the Overview and Changes tab. They could be standalone threads that need to be resolved or they could be replies other other threads. As a result users are scrolling and clicking in different tabs to find the comment. - :tv: [Video walkthrough ](https://youtu.be/y-_XbYSBLbY?si=JqptbVotnkNyKh56&t=140) - :joystick: [Prototype](https://www.figma.com/proto/4KVQUkUDoZilkO4D1o1bvw/branch/30KizaghJuLQCESTZ74NRV/Merge-request?page-id=10613%3A249322&node-id=10918-87398&viewport=-63591%2C-39492%2C1.02&t=67zeiCVJRgQ9dDyZ-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=10918%3A87398&show-proto-sidebar=1) #### How does this approach differ from the "unresolved threads" next/prev buttons? By using the review panel it allows the author/assignee to have a filtered view of comments specific to a reviewer. This could help with getting approvals from some reviewers sooner than later. #### How does this approach differ from introducing a new tab "Comments"? The "Comments" tab approach was a concept introduced in https://gitlab.com/groups/gitlab-org/-/epics/10146+. The review panel shares similar philosophy in that there should be a way to filter discussions between author and reviewers. The "Comments" tab requires building a new interface in the "Comments" tab to view and interact with comments and changing the Activity feed in the Overview to be summaries that link to the "Comments" tab. The review panel is only a list of comments. To interact and comment the user would need to navigate to the comment in context of the merge request to respond. By doing this approach doesn't require new comment interaction pattern, allows the user to view full context of a discussion, and leverages the existing functionality of file diffs. #### How does this approach differ from review rounds? A high level concept of a review round https://gitlab.com/groups/gitlab-org/-/epics/9577 is the idea that the interaction between a merge request author and reviewer is turned based where the author requests a review and then waits for the review. A reviewer reviews and provides feedback then waits for the author. In reality reviews may not resemble a perfect process that results in a clear points of handoff. Also the fact that comments for a review could be standalone comments or replies in threads makes it hard to see what has been resolved in [a traditional threaded-conversation view](https://gitlab.com/gitlab-org/gitlab/-/issues/430123/designs/review-summary-requested-changes.png). Rather than trying to force that all feedback in a review needs to be resolved before re-requesting a review. We should embrace the team will resolve the outstanding comment before merging but there could be other aspects of the review that could be resolved/approved to help progress the merge request discussions. Example: There could be a review where there are a lot of small fixes to be addressed but one point where the reviewer and the author are not sure of how to progress. Should it block getting the reviewer's feedback on changes to address the small issues? In reality you would say something like "I'll approve once you address that one point, the rest of the changes look good to me". | Reviewer - Provides initial review | Author addresses most, re-requests review | Reviewer - Happy with fix but approval is pending addressing outstanding item | | ------ | ------ | ------ | | ![image](/uploads/6d7685f612350b49b852b63a72fb87f5/image.png) | ![image](/uploads/6952fe7124b377412dd5c6a3cdbd12ed/image.png) | ![image](/uploads/6d28feeba572d92b0b8acd9d22929e07/image.png) | ## Discussions - How does this handle the case of an approval being removed after commit push? https://gitlab.com/groups/gitlab-org/-/epics/14651#note_2023445349 - Filtering the review timeline https://gitlab.com/groups/gitlab-org/-/epics/14651#note_2023597426
epic