[go: up one dir, main page]
Skip to content

Code Review UX Roadmap

Purpose

There are many initiatives we're currently working on in Code Review that will require UX to lead efforts and then provide supporting assistance. The goal for this issue is to first generate a list of all of these efforts, and then we'll work to prioritize that works since we'll likely need to "say no" to some items.

Vision

The vision by addressing the top priorities is to have the following experience:

  • Reviews are a first class workflow in GitLab
    • The code review workflow that can be used to understand who and what action is needed to get the change merged.
    • The reviewer has a key role. They are not unassigned and empty when changes are merged
    • The concept that a reviewer provides an appproval will extend from approval rules, CODEOWNERS, and to security policies: "Hey Grant, can you review this code that addresses the security violation this MR introduced?"
  • Clarity of the state of a merge request
    • Nobody needs to scroll to some random part of the page to figure out if the MR is mergeable or what's outstanding in a merge request
    • You can jump straight into a checks report or a reviewer's review.

📺 Video walkthrough (24 mins - There are chapters)

We came to the top priorities by looking at the outcome statements of the JTBD for Code Review.

Method: Using JTBD and outcome statements to highlight opportunities

For prioritization in the world of JTBD and outcome statements, it is best to address outcome statements with the highest opportunity scores. Opportunity scores are calculated based on users ratings of the solution's satisfaction and importance to the outcomes of a job step. There are 3 outcomes for speed, reliability, and efficiency for every job step. The Code Reviewer has 66 outcome statements.

image

Using the existing outcomes has shown that refinement of these scores will be necessary to be done as many outcome statements are blank. We have plans to address them across to FY24Q3. Although many outcome statements were missing, I still believe it provides an accurate picture of the underserved outcomes as it aligns to past prioritization work https://gitlab.com/gitlab-org/create-stage/-/issues/12890#note_645081983 and this issue's description of list of unprioritized roadmap work that have not been fully addressed yet today.

The underserved outcomes were:

  • Minimize the time it takes me to understand the context of a merge request (as a reviewer).
  • Decrease the time it takes to ensure code I'm reviewing complies with team procedures / standards.
  • Increase the efficiency of reviewing and understanding comments from other reviewers.
  • Increase the efficiency with which I can examine proposed code changes.
  • Increase my ability to assess the larger infrastructure impact of the proposed changes (during a code review).
  • Minimize the effort it takes to ensure that proposed code changes have proper test coverage.
  • Minimize the effort needed to keep track of a merge request.

Top 3 priorities

  1. Increase the efficiency of reviewing and understanding comments from other reviewers [Opp score: 10.38]
  2. Minimize the effort needed to keep track of a merge request [Opp score: 10.91]
    • Monitoring the merge requests from draft to merged state in one view
    • Also addresses these outcomes that are "properly served"
      • Minimize the time it takes to figure out which review requests I have already reviewed.
      • Increase the efficiency with which I can prioritize my review requests.
      • Decrease the time it takes me to select an merge request to review.
  3. Minimize the time it takes me to understand the context of a merge request (as a reviewer) &15891 [Opp score: 13.40]

Priorities 1 and 2 are being looked at in parallel at the moment. If we follow the spreadsheet (tab: Outcome prioritization) and tackle the highest opportunity score then we would have addressed Merge request overview tab improvements to conv... (&13632) first. However I believe there is a reason not to do this first but rather third after the we improve the reviewing process and merge request homepage. The idea is that the homepage work is exploring status presentation, the review workflow will look at where review/approve actions will go, and both will help inform along with past explorations (&5038 (closed)) of context changes will land.

Addressing other outcomes

With the top 3 priorities, it provides a solid foundation for the following opportunities to get the maximum impact. The following items have not been prioritized yet. Issues and epics added to this list are not definitive as there might be items we have not included:

Increase the efficiency with which I can examine proposed code changes.[Opp score: 11.54]
Maximize the efficiency with which I can submit a comment during my code review. [Opp score: 8.18 (Properly served)]
Minimize the time it takes to set up my environment for a code review. [Opp score: 8.98 (Properly served)]

Example of a need to revisit the JTBD and job steps because flows to improve getting from code to code in action for review would help with reviews.

Increase my ability to assess the larger infrastructure impact of the proposed changes (during a code review). [Opp score: 13.15]
Minimize the effort it takes to ensure that proposed code changes have proper test coverage. [Opp score: 12.0]

Could auto generation of tests work here?

Increase clarity in feedback in code review [new]

Other top of mind

Initial roadmap starter items
Edited by Michael Le