Design framework for MR merge widget

After mapping the merge button states, we should be knowledgeable enough to make better design decisions and create a design framework that allows for multiple stages to evolve its behavior.

Design principles

1. Scalable, allowing for many actions and information elements.
2. Includes “edge” states, like empty, loading, or error.
3. Supports “merge” options, like deleting the source branch, rebasing, and others.
4. Clear structure for actions, options, and support information.
5. Disabled states of merge button have clear and concise explanations, and next actions.
6. Users that don't have permission to merge are considered.

Breakdown

In order of RICE score:

1. &5589 (closed) Restructure MR merge widget — (R6 * I2 * C1)/E1 = 12
   1. Re-order merge options and action
   2. Move allow collaboration alert to branches widget
   3. New placement for merge/rebase errors
   4. ==TODO: solve SHA mismatch state==
2. #323061 (closed) UI text improvements — (R6 * I1 * C1)/E.5 = 12
   1. Random positive messages when ready to merge and merging. We could ask the community on social media to suggest messages.
3. UI polish: Size and style of main MR widgets icons — (R10 * I.5 * C.5)/E.5 = 5
4. UI polish: Style of headings, text, and links of all MR widgets — (R10 * I1 * C.5)/E1 = 5
5. List merge checks — (R1.5 * I2 * C.8)/E1 = 2.4
6. Re-order merge checks — (R3 * I.25 * C.5)/E.5 = 0.75

Future

1. Placement of CI warnings that influence user's decision to merge — in pipeline widget or merge widget? #299195 (comment 516430236)
2. #325529 (closed) Text and interaction design of MWPS/MT/MTWPS: move to the concept of auto-merge, used by competitors.