[Design] Merge request homepage redesign

Problem statement

The merge request homepage redesign aspires to enhance the user experience for both authors and reviewers, making it more efficient to manage merge requests throughout the entire code development cycle.

Navigating and managing Merge Requests (MRs) in GitLab is currently challenging, making it difficult for users to monitor the merge requests from draft to merged state in one view. GitLab should minimize the effort needed to keep track of a merge request(link).

Proposal

Enhance the user experience for authors and reviewers by making the merge request homepage efficient in managing merge requests throughout the development process. The redesign aims to:

  • Minimize the time needed to identify which merge request needs attention.
  • Reduce the effort required to get the status of merge requests.
  • Decrease the likelihood of selecting a low-priority merge request to review first.

Design goals

  • Clarify responsibilities:

    Provide clear indicators showing whether an MR needs the attention of the author or reviewer.

Product goals and directions

Release a working prototype so we can test it internally with GitLab internal employees and collect feedback. We want to release this as fast as possible in order for us to do that, there are some tech considerations that will limit the scope of this working prototype, such as filter and search: #430735 (comment 2000213599)

Button for switching the experiment

We will implement a button that allows users to switch the experiment on and off, enabling them to use the filtering and search features that are currently out of scope.

More about what we want to track and how we are implementing: #475243 (closed)

Sections for the MR homepage

The MR homepage needs to clearly indicate the responsibility status for each MR, whether it is pending review, requiring changes, or awaiting further action from others.

  1. Returned to you
    • MRs assigned to you that have been reviewed and returned for changes.
  2. Review requested
    • All MRs that have requested your review.
  3. Assigned to you
    • Drafts
    • MRs assigned to you, with no reviewers.
    • MRs assigned to you that have been approved by other reviewers but have merge conflicts.
    • MR's assigned to you that have been approved by other reviewers but auto-merged failed.
  4. Waiting on others
    • MRs where you are the assignee waiting for other reviewers to complete the review.
    • MRs where you are the reviewer and have requested changes.
  5. Approved by you
    • MRs that you have approved.
  6. Merged recently
    • MRs merged from the last 2 weeks where you are the assignee.
    • MRs merged from the last 2 weeks where you are a reviewer.

Navigation count customisation

From #430735 (comment 1977173495)

One of the things we talked in the past that I feel is still missing is the customisation. It'll be VERY hard to arrive at a Smart Default that covers the majority of our users' preferences. Customisation could be a key factor both as practical solution as well as "promise", especially on a first impression (having the fallback to still have a legacy Dashboard/search view minimises the risk, but the "wrong" navigation count will keep feeding anti-pattern behaviours like unassigned themselves as reviewers. So I'd argue we need to have some very basic form of affecting the count.

  • Reasoning: The "Assigned to me" section seems important to have on display, but not affect the count. Some other users will want them to increase the count.
  • Dev note: We also need to investigate from an implementation side the performance impacts and concerns we need to put in place to be able to achieve a customised query for the Nav Count that is displayed on ALL pages based on a user preference, so the earlier we start, the better.

We could run some experiments by modifying the merge request count displayed in the navigation to ensure it only includes the most critical MRs, excluding those that do not require immediate action. Making it more meaningful and manageable.

Include in count:

  • Returned to you
  • Review requested
  • Assigned to you

Exclude from count:

  • Waiting on others
  • Approved by you
  • Merged recently
Original issue description

Problem

It's difficult to know what needs your attention and what doesn't in GitLab, specifically around Merge Requests (e.g. moving your MRs through the process, reviewing MRs when requested). For example, at GitLab we have adopted the workaround of removing ourselves as reviewers from Merge Requests so that we don't see its number in the notification badge, and so that subsequent requests will notify us.

As stated here, GitLab should make it easy to distinguish between MRs that require your attention and MRs that don't.

  • As an author (Assignee)
    • Which MRs have reviewers responded to that I need to address their feedback on?
  • As a reviewer (Reviewer)
    • Which MRs need my review or approval?

Proposal

The current issue proposes ways to clarify who has responsibility for a merge request, whether it's a reviewer who has been requested to review, an author who needs to respond to a finished review, or a reviewer who has been re-requested to review.

Previous research/efforts

Initial lists for MVC:

  • Approved by others
    • Merge requests assigned to you approved by other reviewers.
  • Returned to you
    • Merge requests assigned to you, reviewed by others, and returned to you for additional changes or feedback.
  • Review requested
    • Merge requests assigned to others, that have requested your review.
  • Assigned to you
    • Merge requests assigned to you.
      • Drafts,
      • MRs assigned to me but no reviewer
  • Waiting on others
    • Merge requests where you are the assignee and have requested a review.
    • Merge requests where you are the reviewer and have requested changes.
  • Waiting on others as a reviewer
    • Merge requests where you are the reviewer and have requested changes.
  • Approved by you
    • Merge requests approved by you.
  • Merged recently
    • Merge requests merged where you are the assignee.
    • Merge requests merged where you are a reviewer.
    • Within the last 2 weeks.

Merge request count

Include in count:

  • Approved by others
  • Returned to you
  • Review requested
  • Assigned to you

Exclude from count:

  • Waiting on others (Assignee)
  • Waiting on others (Reviewer)
  • Approved by you
  • Merged recently
Edited by Alex Fracazo