### Problem to solve <!-- 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)." --> One participant in the SAST to Complete CMS was tasked with enabling SAST, but was blocked by merge conflicts. She's a new developer and new to git, and did not understand how to proceed. Her struggle can be boiled down to two problems to solve: - She didn't understand the meaning of `use theirs` vs `use ours` - She didn't understand that she had to choose one of the above options in order to proceed, possibly because they don't look like buttons used elsewhere in the GitLab UI Screenshot:  ### Other info I brought this up in [Slack](https://gitlab.slack.com/archives/C03MSG8B7/p1620084268383400). Here's the transcript: Becka (me): @pedroms I'm not sure if your team "owns" this part of the MR experience, but I noticed that when there are merge conflicts, we have "use theirs" and "use ours". This came up in a SAST CMS interview when the participant (a developer) was trying to enable SAST and she wasn't sure how to proceed. Starting at 13:59 of this [video](https://dovetailapp.com/projects/54a366ef-ee3b-4a20-886b-3444a0bc4508/data/aaf59de1-6b76-49c2-8544-8b405968af85) (going until about 15:50), I ask her, "Is that clear to you what that means - use theirs vs use ours?" Her response was, "Yes" at first, but then thought about it more and changed her answer to "No" (it's not clear). She then adds, "I assume that GitLab is theirs ...". I didn't dig into this too much because I had to be mindful of time and make sure I completed all of my scenarios for the CMS, but I thought this terminology was interesting (theirs I assume is the other person trying to merge conflicting code to the same branch and ours are the owner(s) of the MR in which we were in (?) and the buttons don't quite look like buttons here either. @jboyson: FWIW ours/theirs is `git` specific verbiage. Context: https://stackoverflow.com/a/25576672/2892106. Not saying we can’t make it better, but it is (for better or worse) industry standard. Becka (me): @jboyson Interesting, thanks! Curious how many developers are familiar with this. The developer I spoke with was less experienced (I believe she completed a bootcamp and this is her first job) so for users like that I think it could be helpful to include a tooltip or some kind of explanation on what this means, but curious to hear if any of the designers or researchers have heard specific feedback on this or not. @jeldergl: And there are situations where ours and theirs can flip if I remember right. Like during a rebase. Does that sound right @jboyson? @jboyson: Sadly, yes. I think you are correct. I have several seasoned developers that basically don’t know anything beyond `git checkout/pull` ### Intended users Anyone who is trying to merge an MR (possibly all personas), and especially [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> - Developers new to Git understand how to resolve merge conflicts - Developers new to Git can quickly and easily figure out the difference between `use theirs` and `use ours` - Developers new to Git understand they need to choose one of these options in order to resolve conflicts and thereby unblock the MR ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Possibly both problem validation (if none has been done in this area) and if problem is validated, do solution validation on 1 or more design explorations ### Documentation <!-- 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 --> The [MR docs page](https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html#resolve-conflicts-interactive-mode) doesn't appear to go into the difference between `theirs` vs `ours`, and the screenshot there appears to be outdated. cc @aqualls ### Available Tier <!-- This section should be used for setting the appropriate tier that this feature will belong to. Pricing can be found here: https://about.gitlab.com/pricing/ * Free * Premium/Silver * Ultimate/Gold --> All tiers ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. Create tracking issue using the the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> ### Is this a cross-stage feature? <!-- 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 --> Yes, many stages involve CI/CD but this primarily falls under the [Code Review](https://about.gitlab.com/handbook/product/categories/#code-review-group-1) group