Replace merge strategy labels with `Auto-merge` and change help text
Release notes
Problem to solve
In the design below users expect to see more clarity in how auto-merge differs from a regular merge and what are the things that will be done differently. That would give them more confidence in setting their MRs on auto-merge,
Intended users
- Delaney (Development Team Lead)
- Presley (Product Designer)
- Sasha (Software Developer)
- Simone (Software Engineer in Test)
User experience goal
Insights:
- Communicate the difference between auto and manual merge clearly
- Illustrated progress in the widget and adds to user's confidence
The user goal is to provide users with enough clarity so they could confidently proceed with opting for auto-merge.
Proposal
As learned from the findings in https://gitlab.com/gitlab-org/ux-research/-/issues/1568#-findings, make improvements to the help text in the widget to communicate the process of auto merge more clearly.
Questions to Answer
-
What E2E or Integration tests need updated with this change? - @richard.chong
Further details
Permissions and Security
This will not change who can and cannot click the button.
Documentation
As discussed in #359057[auto-merge.png] (comment 1120024240), we'll need to document the new auto-merge
button, and explain clearly how it works in different cases (with/without merge trains enabled, etc.)
Availability & Testing
With regards to tests that might be affected by this change, I'll list out the potential E2E tests that might be affected by this:
qa/specs/features/api/3_create/merge_request/push_options_mwps_spec.rb
qa/specs/features/browser_ui/3_create/merge_request/merge_when_pipeline_succeeds_spec.rb
In general, I'd recommend manually triggering the full suite of E2E tests in the MR pipeline when we work on this to make sure all the E2E tests are still passing after changes are introduced.
Available Tier
- Available starting in GitLab Free note that Merge Trains is a GitLab Premium feature.
Feature Usage Metrics
We'd expect this clarification to have positive impact on MRs merged and pipelines ran.
What does success look like, and how can we measure that?
This change intends to clarify what clicking the button does and reassure users they are doing the right thing with the MR. This will result long term in fewer support tickets/forum questions/etc. and in the short term small growth in MRs merged / pipelines ran.
What is the type of buyer?
Is this a cross-stage feature?
Yes, groupcode review who manage Merge Requests has been involved/consulted on the new design.
What is the competitive advantage or differentiation for this feature?
Links / references
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.