2019Q2 Exp. recommendations for Creating a Merge Request

Job To Be Done

Creating a Merge Request: When I think my work is done or I need advice, I want to know what changes or improvements are needed, so that my work can be merged knowing it will behave as expected.

Experience baseline

#441 (closed)

Recommendation summary

Other recommendations

Approval rules

This was the one task in the merge request context that users were struggling with the most. It adds a huge amount of complexity, especially with the unclear distinction between assignees and approvers. As this is a highly complex feature, and engineers from both frontend https://gitlab.com/gitlab-org/gitlab-ee/issues/1979#note_117272808 and backend https://gitlab.com/gitlab-org/gitlab-ee/issues/1979#note_132387817 have already mentioned the huge amount of different cases and dependencies. Additionally, users have already complained that the version is more intended for GitLab Premium and does not work for GitLab Starter https://gitlab.com/gitlab-org/gitlab-ee/issues/12185.

Taking the large amount of complexity and work that has already been done into account, I would recommend first doing a usability study, so that we can figure out how users experience the feature and where their biggest problems are. I have already created a research proposal for this ux-research#270 (closed).

Afterwards we should plan a redesign to address the problems and test the new design again with users to see whether and how much progress was being made.

The epic &1709 (closed) lists small improvements that can be made sooner to clarify approvals and avoid hiccups.

Changing branches

Two main problems have to be solved: It needs to be possible to change the branch without losing progress that was being made for descriptions and metadata. And it also needs to be more visible which project I'm merging into if I'm working in a fork. This is something that's already being reported as a bug by our community members https://gitlab.com/gitlab-org/gitlab-ce/issues/64387 https://gitlab.com/gitlab-org/gitlab-ce/issues/64093, and there is an ongoing discussion around it https://gitlab.com/gitlab-org/gitlab-ce/issues/22090.

Templates

Most templates are actually forms the user has to fill out. We could consider offering an improved template version that gives the user the option to provide all form inputs in a yaml file that then gets rendered as a usual form for the user. I have created an issue for this https://gitlab.com/gitlab-org/gitlab-ce/issues/61712.

Quick actions

Quick actions for labels and milestones have to be synced up with the respective form fields. If I add a label via a quick action, it has to show up as selected in the "Labels" dropdown https://gitlab.com/gitlab-org/gitlab-ce/issues/64654.

Labels

To get a better overview of which labels are already selected and also to remove them quicker, we might be able to take over the solution from https://gitlab.com/gitlab-org/gitlab-ce/issues/28804.

Tasks

  1. After completing the Experience Baseline for a JTBD, brainstorm opportunities to fix or improve areas of the experience.
    • Use the findings from the Emotional Grading scale to determine areas of immediate focus. For example, if parts of the experience received a “Negative” Emotional Grade, consider addressing those first.
  2. Create an issue for each recommendation and add them as related to this issue.
  3. Think iteratively, and create dependencies where appropriate, remembering that sometimes the order of what we release is just as important as what we release.
    • If you need to break recommendations into phases or over multiple milestones, create multiple epics and use the Category Maturity Definitions in the title of each epic: Minimal, Viable, Complete, or Lovable.
Edited by Pedro Moreira da Silva