Multiple Approval Rules regresses UX experience for opening MRs

Summary

Multiple approval rules drastically changed how approvers are added to MRs for Gitlab Premium users. The new UX path for adding an approver to an MR got 5x longer for no additional benefit to us and cannot be disabled.

What is the current bug behavior?

Prior to Multiple approval rules (and presumably still is for non-Premium Gitlab installations), adding a reviewer to the code review was a one-UI-screen processes with one step:

1. From the MR add the approver's name in the approvers input field

Now it is a multi-screen, multi-step process:

1. From the MR click Add approvers
2. In the modal dialog:
   1. Fill in a name
   2. Type an approver into the members field
   3. Click Add
   4. Click Add approvers to close the dialog

This is a huge UX regression for our 80 developers who don't need the additional complexity that this new feature introduced.

What is the expected correct behavior?

Our developers just need to add approvers to an MR. While the multiple approval rules would come in handy for one or two MRs per month, adding the UX burden to every MR is not worth the overhead.

Some possible UX things to consider to mitigate the issue:

• Making the "name" field in the modal dialog optional (I can't tell you how many of our MRs just have asdf for this right now). This isn't a solution, but it would lessen the immediate pain.
• Allowing multiple approval rules to be enabled/disabled and if disabled it uses the simple add-approvers UI. This is non-ideal, but would at least allow us to turn it off.
• Ideally, default to the simple add-approvers UI and allow the person opening the MR to switch to the multiple approver rules UI for the (rare) cases when it is needed.