<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### 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,  <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) ### User experience goal Insights: 1. Communicate the difference between auto and manual merge clearly 2. 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 - [x] What E2E or Integration tests need updated with this change? - @richard.chong ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Permissions and Security This will not change who can and cannot click the button. ### Documentation As discussed in https://gitlab.com/gitlab-org/gitlab/-/issues/359057/designs/auto-merge.png#note_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.) * [MWPS](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html) * [Merge Trains](https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html) <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### 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: 1. `qa/specs/features/api/3_create/merge_request/push_options_mwps_spec.rb` 1. `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? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers --> ### Is this a cross-stage feature? Yes, ~"group::code review" who manage Merge Requests has been involved/consulted on the new design. <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### What is the competitive advantage or differentiation for this feature? ### Links / references <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->