Access multiple merge requests that need attention based on approvals information

Solutions

• https://gitlab.com/gitlab-org/gitlab-ee/issues/1315 View approval counts in the merge requests list view
• https://gitlab.com/gitlab-org/gitlab-ee/issues/1316 As a merge request approver, view if I have approved in the merge requests list view
• https://gitlab.com/gitlab-org/gitlab-ee/issues/1317 View if a merge request has all the required approvals met in the merge requests list view
• https://gitlab.com/gitlab-org/gitlab-ee/issues/1318 View detailed approver information in the merge requests list view

Problem

There are a few scenarios in which people need to access multiple merge requests based on approvals information. The scope of this issue is to design and implement one or several solutions to address these problems:

• As a code reviewer and merge request approver:
• I want to know how many merge requests need my review and approval, or at least get a sense of how many.
• I want to know which merge requests need my review and approval, and be able to navigate to any specific one quickly.
• I want to know other people who can approve a merge request (and those that have already done so), so that I can nudge them if I don't have time to do it myself.
• I want to which merge requests are high priority, or deserve my attention. For example, if there's one merge request that needs one more approval, and I'm the only person left who is allowed to approve it, it is currently blocked by my inaction. So I should probably review it and approve it soon. Or suppose a particular feature is deemed high priority, then I should probably review that one first. If many folks are eligible to reviewed a merge request, then that merge request should be lower in priority for me.
• Stretch goal: I want to know exactly which merge request I should work on next.
• As an engineering manager / engineering lead:
  • I want to know which merge requests are done code review and have all required approvals, and are ready for merging in.
  • I want to know which merge requests are close to be done for code review and approval, and which ones still need a lot more work.
  • I want to know which team members can approve a merge request, so I can nudge them with a reminder.
  • I want to know which team members have already approved a merge request, so that I don't have to bother them, or that I can thank them.
  • Stretch goal: I want to know exactly which next merge request deserves my attention.

Product and design considerations

• The stretch goals are harder to solve, and likely can be managed manually be a team. The workflows may be very specific to teams. So it's not a good idea to focus on these problems in the initial designs and implementations. (But if a proposed design can solve them too, then that is great.)
• We should design for the scenario of a small number of required approvals per merge request. Designing for a scenario for say, 100 approvals required is unrealistic in most cases, and outside the scope for this particular issue. Furthermore, it may be typical for a person to be requested as an approver of 20 to 30 open merge requests, in a large organization.
• The designs should be consistent with the design of the view in a single merge request (https://gitlab.com/gitlab-org/gitlab-ee/issues/1262). (Or we should at least harmonize them in future work.)
• We should consider the already many proposals outlined that suggest including more information in each entry of the merge requests list view, and also expanding the filtering/search functionality (https://gitlab.com/gitlab-org/gitlab-ee/issues/765, https://gitlab.com/gitlab-org/gitlab-ee/issues/1106, https://gitlab.com/gitlab-org/gitlab-ee/issues/52, https://gitlab.com/gitlab-org/gitlab-ee/issues/1177, and the comment thread in this issue).
• https://gitlab.com/gitlab-org/gitlab-ee/issues/52 already has a design and merge request (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/620). We should try to reuse as much as possible.