<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=450453) </details> <!--IssueSummary end--> <!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, 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. --> ### Release notes This feature allows the merge request and issues of past changes to lines of code to be summarized so that you can have context around the _why_ faster. Whether you are a new junior developer or an experienced developer, when it comes to knowing _why_ a piece of code was changed is something that is encountered everyday. In the past that involves navigating through past commits and merge requests to piece together that context. Developers now can get a summary of changes in one-click. <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve As a developer, I want to understand the context of past code changes to this section of code so that I can have a better understanding of the rationale used to change the code. ### User experience goal The user should be able to get a summary of past changes and a list of links to those past changes when the user highlights a few lines of code. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> To understand the why of a code change, users will look at the commit history via blame or a list of commits to that file and then navigate back to the linked merge request and/or issue for more context. This requires many actions and pages open to make sense of the code change https://gitlab.com/gitlab-org/ux-research/-/issues/2920#observations. To solve this we would introduce an action that would let you "explain code history". This action would do the following things: - Retrieve all commits that is related to the selected line of code - This would eliminate the need for the user to go through all of the blame views & clicks - From the commits we are able to find the related merge requests - Take all related merge request descriptions and summarize it. - Display back to the user - merge requests summary - list of merge request links collapsed in an accordion to help if there could be a long list If the user doesn't get enough information from the merge requests, we could have a button that says "get issue summary" link to past issues and get the relevant issue descriptions. We could also incorporate a future look ahead of changes by looking at open merge requests that contain the current file and summarize that. This would give the user context of past and future for the selected lines of code. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> TBD ### Documentation TBD ### Availability & Testing TBD ### Available Tier TBD ### Feature Usage Metrics - Count of usage - Number of links clicked per summary - Number of regressions of summary <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? --> ### What does success look like, and how can we measure that? - Becomes main use case of explaining code over current code explaination. <!-- 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. Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide. --> ### Is this a cross-stage feature? This functionality can be leveraged by ~"group::source code" and ~"group::code review" <!-- 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 --> ### What is the competitive advantage or differentiation for this feature? ### Links / references - Relates to explain this code AI feature and summarize merge requests - https://gitlab.com/gitlab-org/gitlab/-/issues/448868+ - https://gitlab.com/gitlab-org/gitlab/-/issues/442849+ <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->