<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> GitLab makes it easy to perform a code review but the process that comes after the initial review is arguably even more important, **how the code review is resolved.** After a code review, the author will address the feedback with various changes and clarifying questions which the reviewer needs to answer and review before approving. This isn't a lack of trust, but a matter of quality and mentorship so that the feedback is addressed in full and correctly. This **post-review pre-approval workflow** is currently very difficult. ### Further details As someone who has done a code review and left feedback, I want to know: - Are there clarifying questions to my feedback that I need to answer? I don't want to leave unclear feedback. - Have my comments been addressed? If they've been addressed, I want to mark them resolved. - If one of the comments has been marked as resolved, was it by me or someone else? I might need to review it if it wasn't an equally senior engineer. - What has changed since I last reviewed the merge request? Complex structural feedback might require a comprehensive review, not simply looking at individual changed lines. As a prospective reviewer/approver/merger, I want to know: - Has one of my colleagues already performed a review? I don't want to pile on needlessly. - Are there outstanding comments? And who were they left by? If there are outstanding comments from someone who has already approved, that's not a big problem, but if a senior engineer has given a review and yet he hasn't approved it I should be cautious to merge prematurely. (They might just be on vacation, so it doesn't need to be blocking) Code review is an expensive process, taking up a significant amount of developers time, and directly impacts the code quality of a project. We should make the **entire code review** process efficient! ### Vision GitLab's code review and approval workflow should be a complete workflow that helps authors and reviewers be confident in every merge request that is merged, without needing to review the same change twice. We should build on **merge request reviews** (née "batch comments") https://gitlab.com/groups/gitlab-org/-/epics/23 to build a streamlined workflow for a reviewer to also review the fixes and comments made by the author. ### Proposal - list who has left a review, and how many of the discussions they started have been resolved - make it possible to filter the merge request to the discussion left by a single reviewer - make it possible to see with what changes a discussion was resolved - make it easy to jump between the discussions I started or have participated in, rather than all discussions - make it easy to access a diff of the changes since I last reviewed the merge request - and probably more... ### Links / references - [Popular ~"code review" issues](https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=code+review&scope=all&sort=popularity&state=opened&utf8=%E2%9C%93)