## Problem to solve From our [research spike](https://docs.google.com/presentation/d/13mr-6CLhQJicjcYjcxme89PtBR97rWZ4GVZMpJSIYHw/edit?usp=sharing) in 12.5, Code Review Analytics was voted as a top priority for both GitLab and customer Engineering Directors. Engineering directors are looking for better ways to improve code review in their teams and need additional data, insights and recommendations to inform their decision-making process. We hypothesise that Directors have 3 key goals to accomplish with code review: * Process - Streamlining my team’s code review process * Product - Protecting my product quality with code review * People - Coaching my people around code review Under each of these goals we have identified some of the most useful JTBD: | # | Situation | Motivation | Outcomes | Strategic/Tactical | | ------ | ------ | ------ | ------ | ------ | | 1 | When I am streamlining my team’s code review **process** | I want to get an overview of the current MRs in review | so that I can follow up on outlier MRs that are too slow or fast | Tactical | | 2 | When I am streamlining my team’s code review **process** | I want to see a trend of the average time it takes for MRs to be reviewed | so that I can see whether we are improving the speed of our review process | Strategic | | 3 | When I am protecting my **product** quality with code review | I want to see any unreviewed MRs that have already been merged | so that I can identify risk and minimise unreviewed MRs | Tactical | | 4 | When I am protecting my **product** quality with code review | I want to correlate code review with changes in quality | so that I can understand how my process is impacting quality | Strategic | | 5 | When I am coaching my **people** around code review | I want to see how responsive and effective a reviewer is | so that I can understand their impact on the team as a reviewer | Strategic | | 6 | When I am coaching my **people** around code review | I want to see how satisfied an author is with an approver | so that I can understand how the reviewer is perceived and how they can improve their practice | Strategic | ## Intended users * [Gabe (GitLab Engineering Director)](https://docs.google.com/presentation/d/13mr-6CLhQJicjcYjcxme89PtBR97rWZ4GVZMpJSIYHw/edit#slide=id.g6bc7f402a9_0_17) * [Dani (Customer Engineering Director)](https://docs.google.com/presentation/d/13mr-6CLhQJicjcYjcxme89PtBR97rWZ4GVZMpJSIYHw/edit#slide=id.g70c1bc449b_0_22) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) ## Proposal **MVC:** [See Mural](https://app.mural.co/invitation/mural/gitlab2474/1575635788584?sender=npost7450&key=e3d2d8a9-f4af-45cf-8c24-00af787b7255) For the MVC, we propose tackling Job Story 1 - this should help to get something relatively useful to a broad audience out quickly, and lay some foundations for deeper analytics along the way.  **Approach:** 1. Collaborate with Create:Source Code team 1. Define Jobs to be done we wish to tackle 1. Design MVC in 12.6 1. Build MVC in 12.7 1. Test & dog-food with GitLab directors & managers 1. Gather customer feedback ## Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> * Opportunity Canvas TBC * [12.5 Analytics Research Report](https://docs.google.com/presentation/d/13mr-6CLhQJicjcYjcxme89PtBR97rWZ4GVZMpJSIYHw/edit?usp=sharing) * [Code Review Analytics: Solution Discovery Mural](https://app.mural.co/t/gitlab2474/m/gitlab2474/1575635788584/270d8ed1cc71cef4977b96ce801c4d7c57c34cff) ## What does success look like, and how can we measure that? * MVC shipped within one milestone * MVC receives user & GitLabber feedback <!-- 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? Ultimately, we will consider analytics at all buyer levels, but for the MVC I propose project-level analytics for a **Starter Buyer**. ## Links / references * [Code Review: category strategy](https://about.gitlab.com/direction/create/code_review) * [Code Review: competitive landscape](https://about.gitlab.com/direction/create/code_review/competitors) * [Code Review: Master Synthesis](https://docs.google.com/document/d/1YBA3ieCAy2YJlkvU7botcfj2-76TmspEWpwcQiiPcuA/edit) * [Ideas for the future of Merge Requests](https://www.youtube.com/watch?v=KpdvIU6hv94) * [Create:Source Code UX Showcase](https://docs.google.com/presentation/d/1Z6hih0g9eeSllc6_FiWg4GR4m22vyUJNEYExN8cfZ8I/edit#slide=id.g29a70c6c35_0_68)