### Problem to solve <!-- What problem do we solve? --> Code hotspots are important to identify and visualize due to the usually high correlation between code stability and code quality. As a result managers want to understand where their hotspots are at a certain point in time and potentially use these in order to prioritize technical debt. It might be the case that a single module has too many responsibilities and refactoring it into multiple ones with separate ones can stabilize that segment of the code and lead to less quality issues. While there will be false positives in what we consider an MVC for code analytics, by adding further analytics, we hope to help the management of complex interaction between modules and engineers. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> EM, PM when overseeing refactoring, Senior Tech Executives ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> - Let's create a treemap where the size of each square is the LOC added/removed during the period (or folder > project > group): https://ecomfe.github.io/echarts-examples/public/editor.html?c=treemap-visual. - The color of the squares should range from green to red and corresponds to areas, which we believe are hotspots, where the more we believe an area is code hotspot, the more `red` the file becomes. - We should have a dropdown to calculate this for a period of time we select by: 1) average time between commits to a file (the lower the time, more of a code hotspot) 2) the number of commits that touch upon that file (the higher, the more of a code hotspot) (the aggregation is: average number of commits per file). ** We are doing only 2) for the first iteration - The treemap should know our hierarchy, i.e. group > project/subgroup & project > folders > files, so that every time you click on a rectangle, it creates a new treemap, with the data inside it zoomed (basically trying to get something similar to http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022). We should be able to see the following information as a tooltip or within the rectangle: LOC changed, N of commits, average time between commits (**latter not required for first iteration**). @aakriti.gupta, you can check https://github.com/adamtornhill/MetricsTreeMap for inspiration. - The filter from https://gitlab.com/gitlab-org/gitlab-ee/issues/12104 should apply but we can downsize the issue depending on identifying any complexities to potentially start with the files in 1 project without any filtering. **First iteration will be 1 project** ### 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)? --> Inline with the rest of the analytics pages now, this feature will be available for Premium users only. Users should only see groups/projects/subgroups that they have a reporter access to and above. For gitlab.com, we will only show the groups, projects, subgroups that fall under namespaces of silver (aka premium) and above. ### 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 --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### 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. --> We will want to see weekly engagement with the page. ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> Director, but would be beneficial at every layer. ### Links / references ### Solution Let's create a tree chart with 4 shades of green, one orange and one red:  **This is how the progression of drilling down would work, but the first iteration should only be project level, I.e. the last screenshot.**  [Click-through prototype](https://sketch.cloud/s/gb9OJ/a/oWyQ8n/play) We can show 2 levels of data: the top levels are separated by an 8px white border, the second level boxes by a 4px border. The user sets the timeframe on the top left, so let's explicitly state what date range we're showing data for:  As the user drills down, we add the levels to the "breadcrumbs" so that they have an overview of where they are and so that they can navigate back to previous levels by clicking on them:  When the user hovers over the box we show the popover:  Let's "wrap" the chart on mobile screens to keep the charts usable: