<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve It is hard to keep track of certain kind of activity, in this particular feature proposal, how many Merge Requests an individual _reviews_. This is interesting for the Developer, as they for example could see _if they_ are at capacity with reviews. It is also interesting for Developers to find another developer that is not "at the limit" when it comes to reviews. For Development Team leads it can be interesting to see how much time is spent on reviews in order to account for it in a planning phase. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### User experience goal JBTD: When I have an MR that needs reviewing, I would like to understand which reviewers/maintainers are available for review, so that I can confidently assign them to review my MR. ### Proposal I have built this prototype for a dashboard: https://gitlab-org.gitlab.io/gitlab-roulette/  This dashboard functions on _the group level_ (gitlab-org) in this example and combines the following information: 1. Availability: Whether a person is available or not. If they aren't available, they can be hidden from the view. Currently GitLab does support setting a status, but we do not know whether a person is _available_ or not. This could be beneficial in other views in GitLab as well and might not be needed for an MVC. 2. Category: Each Person has one or more "categories", e.g. Backend Maintainer / Frontend Maintainer. We don't have the possibility to set this currently in the product, only could fall back on a persons role (e.g. Maintainer, which wouldn't differentiate between Frontend / Backend for example) 3. Currently assigned Review MRs: All MRs in that group that are assigned which are not authored by the user. 4. Review assignment events: All assignment events of Review MRs. I am currently parsing system notes and do not know whether the data is available in products. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members --> ### 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. --> ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### 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 --> ### Links / references