Approve additionally

At the project level, you set the number of required approvals per mr.
At the mr level, you can make the required number greater than the project level number. It cannot be smaller.
At the project level, you can specify people as approvers per mr. If you specify a group of people, it is equivalent as if you added all those people in the group one by one.
At the mr level, you can add more people as approvers for that mr. (But you cannot remove previously specified people.) If you specify a group of people, it is equivalent as if you added all those people in the group one by one.
Based on the above, given any mr, there is:
- A required number of approvals, call it m.
- There is a set of explicit approvers. Call this set Ω This set is generated from above, minus the mr creator if the mr creator is in the above set. Also, this set is made by "unraveling" all the group approvers. I.e. if group A was added as an approver, and that group has 3 people in it, then Ω has those 3 people as distinct members. Let the count of this set be n, i.e. count(Ω) = n.

Scenario	Result
`m <= n`	Only members of `Ω` can approve. In particular, these members will see one of `{Approve, Approve additionally, Remove approval}` in the UI. Every other user will not see this UI.
`m > n`	Members of `Ω` and members of the project (except the mr creator) with Developer role or higher can approve. These people will see one of one of `{Approve, Approve additionally, Remove approval}` in the UI. Every other user will not see this UI.

Approve additionally

If you are a user and you can approve (based on above), you see one of {Approve, Approve additionally, Remove approval} in the UI.
Let p be the number of approvals that the mr current has.
- If you have already approved the mr, you see Remove approval.
- Otherwise if p < m, then you see Approve.
- Else p >= m, and you see Approve additionally.

What this changes

Note that this scheme simplifies the existing implementation. It decouples who can approve a mr from the current count of approvals in an mr and the identity of those approvals. Depending on the two scenarios above, if you can approve, you can always approve (up to the edge cases below).

Edge cases in future issues

These are edge cases that should be handled in future issues. For this issue, these conditions/scenarios are not well-defined, and we should not dictate what happens under these conditions. I.e. there is no requirement for what happens. Whatever happens, happens.

Out of scope

The functionality of how the messaging behaves and the avatars are not in scope for this issue. They will be handled in future issues. Some of the earlier discussion and design is in https://gitlab.com/gitlab-org/gitlab-ee/issues/1126 for reference.

Design

Note: Specified approvers still needed to approve although not visible in the mockups above, will continue to stay visible. They are positioned right after Requires X more approvals

Because of this there is an edge case, with being able to approve additionally while still waiting for someone specified to approve, this looks like:

Edited Jan 28, 2018 by Victor Wu