The following 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.
| Stage | Create |
| Maturity | Loveable |
| Content Last Reviewed | 2023-01-26 |
Thanks for visiting this direction page on Code Review in GitLab. This page belongs to the Code Review group of the Create stage and is maintained by Kai Armstrong (E-Mail).
This direction is constantly evolving and everyone can contribute:
Code Review is an essential activity of software development. It ensures that contributions to a project maintain and improve code quality and security, and is an avenue of mentorship and feedback for engineers. It can also be one of the most time consuming activities in the software development process.
GitLab's guiding principle for Code Review is: Reviewing code is an activity that ultimately improves the resulting product, by improving the quality of the code while optimizing for the speed at which that code is delivered.
The Code Review process begins with authors proposing changes to an existing project via a change proposal. Once they've proposed the changes they need to request feedback from peers (Developers, Designers, Security and Operations Teams, Product Managers, etc) and then respond to that feedback. Ultimately, a merge request needs to be approved and then merged for the Code Review process to be completed for a given changeset.
GitLab's vision for code review is a place where:
In GitLab, Code Review takes place in the merge request. GitLab should make these tasks efficient and easy, so that velocity and code quality and security both increase while allowing for future iterations.
The code review process involves at least two roles (author, and reviewer) but may involve many people, who work together to achieve code quality standards and mentor the author. Furthermore, many reviewers are often not Developers. Reviewers may be Developers, Product Designers, Product Managers, Technical Writers, Security Engineers and more.
In support of GitLab's vision for code review, areas of interest and improvement can be organized by the following themes:
Feature Enhancements
In Progress: Real-time merge request updates
While viewing a merge request, changes can be made to the merge request via pushes, approvals/comments, other users interacting with the merge request, pipelines completing and many other actions. These changes can impact the state of the merge request or the information that you need to review. Ensuring that actions update the merge request in areas like approvals, merge widget, and changes will build confidence with the merge request.
Later: Expressive merge request comments
Communicating the intent behind each comment left during a review is important for making it clear what needs to be addressed to make the improvement, and what can be addressed in future iterations. One way to solve this is with conventional comments to correctly classifiy the feedback.
Performance & Reliability Improvements
In Progress: Merge request performance roundtables
The performance of the merge request is critical in moving our product forward and improving developer satisfaction with the product. In an effort to take a modern approach with the engineering tools available to us today, we're beginning a series of performance roundtables focused on improving the experience from a core level.
Research & Design Efforts
In Progress: Restructure merge requests
The merge request interface is overwhelming and can be challenging to find the information you need to complete the tasks you're working on. We're exploring several areas to restructure information on the page, remove items where appropriate, and increase the focus on completing the important tasks for merge requests.
In Progress: Review Rounds
Code reviews typically involve multiple rounds of review as feedback is given, iterations made, and re-reviews happen. Understanding which merge requests a user needs to act on and the role they're playing in the merge request is an important part of communicating both state and responsiblity. We're looking in to more structured rounds of reviews to better inform users not only of what action is needed, but also when that action is needed.
The Code Review Group continues to focus on providing real-time merge request updates. Our current focus is on improving real-time updates for the merge button widget:
Research & Design Efforts
Code Review has been focused on efforts related to real-time merge request updates and has recently delivered:
We've also delivered on important updates that finished off work our work to better define mergeability in merge requests:
Other important issues recently delivered by the group can be seen in this list.
GitLab competes with both dedicated and integrated code review tools. Because merge requests (which is the code review interface), and more specifically the merge widget, is the single source of truth about a code change and a critical control point in the GitLab workflow, it is important that merge requests and code review in GitLab is excellent. Our primary source of competition and comparison is to dedicated code review tools. See the best in class analysis for an overview. For a closer look at the user experience and feature set of competitor tools see these details. (Both links are internal only).
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
Code review is used by software engineers and individual contributors of all kinds. Depending on their context, however, the workflow and experience of code review can vary significantly.
We primarily focus research efforts around Sasha (Software Developer).