Writing the changelog can be one of the most time-consuming and stressful part of the release process. RMs have polled the community in the "[Tails-dev] Do you read the changelog?" discussion, to figure out whether it still made sense to have a detailed changelog at all, and if yes, what would be the minimal requirements for it. # Use cases for reading the changelog ## Technical users or occasional contributors - A Determine […] what impact the change might have to me in regards how I use Tails - B. To learn and/or out of curiosity ## Contributors - C. Inspect the history of releases - D. Write release notes # Proposed solution ## Iteration 1: MVP (!153) - Write a program that: - fetches from GitLab the list of issues and MRs closed by a specified set of releases, and presents them together, grouped by milestone, via 1 single user operation; - by default, for each MR, displays the corresponding commit messages. - The RM pastes the output of this program as-is in the changelog file. ## Iteration 2 Publish the information generated by iteration 1 over HTTPS somewhere (so one can click on links to go explore issues/MRs/commits further). # Impact on Tails work The discussion mentioned above seems to tell us that this proposal would: - Make it cheaper to prepare a release - The technical writers may miss the rephrasing step currently done by the RM. - Proposed mitigation: put efforts into "express clearly what we're doing and why" effort via issue/MR titles and commit messages, rather than on the RM-at-release-time's shoulders. - Give technical writers access to the info they need to write the release notes earlier in the release process - Increase the incentive to write good issue/MR titles and commit messages.