<!-- This issue template can be used as a great starting point for feature requests. Learn more about the process: https://handbook.gitlab.com/handbook/product/how-to-engage/#customer-feature-requests. 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 Merge requests based changelogs (as an alternative to commit based changelogs). ### Problem to solve Currently, Gitlab has some built-in ability to generate changelogs through API/CLI/CI. It uses git commit trailers as a source for changelogs. This approach does not work well with all workflows: it requires squashing commits, messages cannot easily be editted after merge, it mixes commit messages (mostly for devs) and changelog (mostly for management/users), etc. An alternative is to base the changelog on merge requests, which often come with additional information about a fix/feature (discussion, iterations, implementation details, screenshots, ci, etc.). This is how Github's `Generate release note` button on the release creation page works. ### 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 are described at https://handbook.gitlab.com/handbook/product/personas/ * [Parker (Product Manager)](https://handbook.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://handbook.gitlab.com/handbook/product/personas/#presley-product-designer) * [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Rachel (Release Manager)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager) * [Simone (Software Engineer in Test)](https://handbook.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://handbook.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://handbook.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://handbook.gitlab.com/handbook/product/personas/#dana-data-analyst) * [Eddie (Content Editor)](https://handbook.gitlab.com/handbook/product/personas/#eddie-content-editor) * [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) * [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) --> Developers: when documenting a feature, they already open a MR with a clear title and a description. This way they don't need to think about their git trailer when they commit or squash&merge a merge request. Even after a merge, they can come back and improve upon the MR title or description. Release Manager: can update merge requests titles after merge to improve both their changelog and their mr history at once. ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ --> See above ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Add an argument `merge-requests` mutually exclusive with existing `trailer` to the API/CLI. When provided, switches to "merge request" mode instead of "git trailer mode". Merge requests are retrieved based on the commit in the given range (probably using the same logic as `https://docs.gitlab.com/ee/api/commits.html#list-merge-requests-associated-with-a-commit`) Otherwise, all existing workflows should work in the same way (possibility to commit the changelog, or just generate it). In future iterations, we could include some more fine-tuning for configuring the changelog (e.g. include/exclude authors/labels, see [github's doc](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)). ### Further details n/a ### Permissions and Security n/a ### Documentation n/a ### Availability & Testing n/a ### Available Tier Free of course (but this being a "nice to have" thing, could understand it only ends up in paid tiers) ### Feature Usage Metrics n/a ### What does success look like, and how can we measure that? Number of time the merge_request mode is used to generate changelog (>20%). ### What is the type of buyer? n/a ### Is this a cross-stage feature? n/a ### What is the competitive advantage or differentiation for this feature? Be on par with github ### Links / references - github's doc: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes <!-- Label reminders Make sure to add the appropriate labels for the product stage and/or group (e.g ~"devops::plan") if known and add a comment tagging the appropriate Product Manager. 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/ Examples: /label ~group:: ~section:: ~Category: /label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate" -->