Workflow
A release notes template Cedric fills from GitHub
Cedric reads the pull requests merged since your last release and drafts two versions of the notes from one template, one for customers and one for the team.
Benjamin Ben HattarRelease notes get written last, on a Friday afternoon, by whoever shipped the most. They open 40 pull requests in tabs, try to remember which ones a customer would notice, and give up halfway with "bug fixes and improvements".
Everything needed is already in the repo. Every merged pull request has a title, a description and an author. What's missing is someone to read all of them and sort them into what customers will notice and what the team needs to know. Cedric does that reading. You ask in Slack, he drafts both versions from one template, and you edit before anything is published.
- Ask for the notes since your last release date. He reads every pull request merged in that window.
- One template gives two drafts: what customers will notice, and what the team needs at deploy.
- You edit in the thread. Publishing the changelog stays with a person.
- Run it on release day, or put it on a schedule once the drafts come out right.
Release day
41 pull requests, two drafts.
Nina Brunner9:14 AM
@Cedric draft the release notes for everything merged since the 6 October release.
CedricAPP9:15 AM
41 pull requests merged since 6 October. For customers, three changes to lead with: CSV export now includes custom fields, large workspaces load about twice as fast, and invited users can sign in with Google. Six fixes worth naming, and the rest are internal. For the team: one migration to run before deploy, and two features ship behind flags. Both drafts are in the thread.
Set it up
- 01
Add Cedric to Slack
Install him and invite him to #product or #engineering. You start with 100,000 free credits, about $50 of work, and no card.
- 02
- 03
Ask for the notes
"Draft the release notes for everything merged since 6 October. One version for customers, one for the team."
- 04
Edit in the thread
"Lead with the export change." "Drop the Google sign-in line, it isn't announced yet." He rewrites and keeps the rest.
- 05
Put it on a schedule
"Every Friday at 15:00, draft the release notes for the week's merged pull requests."
Do it by hand once or twice first. A schedule repeats whatever the draft gets wrong.
The template
Paste this into the channel once and ask him to remember it. It sticks in the workspace memory, so whoever asks next gets the same shape.
The customer version. One headline line for the biggest change. Then New, Improved and Fixed, one line per item, each written as what the user can now do. No pull request numbers and no internal names. End with where to send questions.
The team version. Every merged pull request grouped by area, with its link and author. Then what needs care at deploy, such as migrations, features behind flags and API changes. End with what merged but isn't announced yet, so support isn't caught out.
Add one rule while you're at it. A pull request with a vague title, like "fixes" or "wip", gets a question in the thread instead of a guess in the notes.
What stays with your team
Publishing. He drafts in Slack or a Notion page. The changelog, the customer email and the app store text go out when a person posts them.
What counts as news. He sorts by what the pull requests say. Whether a change is worth announcing, or ready to be, is a product call.
Merges and releases. He reads the repo. Reviews, merges and the release itself stay with your engineers.
FAQ
Yes. Connect GitLab and ask the same way. He reads the merged merge requests for the window you name.
Yes. Support or sales can ask "did the export fix ship?" and get a plain answer without pinging the developer who wrote it.
Into the thread where you asked. Ask and he saves them as a Notion page the team can edit.
He drafts them. Posting is a person's job, the same as the release itself.
Free to start, no card.