<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=230245) </details> <!--IssueSummary end--> <!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> As a reviewer, I use the merge request "Review" feature as a way to draft out all of my comments while I jump around from file to file over the course of a review. Oftentimes, this leads to adding some comments to an earlier file, and some comments to a later file, before going back to the earlier file and adding more comments. When I submit my Review, the comments are added to the merge request "Overview" tab in the order in which I added them to the Review. For larger merge requests, this can lead to forcing the code author to have to jump back and forth between files as they try to follow along with your comments. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. --> Reviewers and developers ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The reviewer should be able to define the order in which their comments will be added to the merge request "Overview" tab before they submit their Review, allowing the developer to easily follow along without having to bounce back and forth between the same files. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> This problem can be solved in one or more ways: 1. Allow for drag-and-drop reordering of the comments in the "Pending comments" list that pops up from the "Finish review" button. 1. Have a checkbox in the "Pending comments" list to enable automatic reordering, grouped by file. - Upon submission of the Review, comments would automatically be placed in the same order that the files appear in the "Changes" tab of the merge request &mdash; first sorted by file, then sorted by line number within the file. Implementing both suggestions would give the reviewer a full array of options for submitting their review &mdash; no sorting, manual sorting, or automatic sorting. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> As a simplified mock example, see the screenshot below:  In this review, I first found a defect on line 77 of `suggestions_spec.rb`, then one on line 613 of `apply_service_spec.rb`, and finally one more back in `suggestions_spec.rb` on line 136. Being able to swap the order of the last two comments before submitting my Review would provide the developer with an easier to follow list of defects to address. ### Links / references Complementary issue: #15265 &mdash; Just as code changes should tell a story, the review of those changes could also tell a story.