GitHub changelog example: from merged PRs to a customer update
See a practical GitHub changelog example that turns raw merged pull requests into a clear, customer-facing product update.
The difference between a GitHub activity log and a useful changelog is not the amount of detail. It is the point of view. Engineering needs the implementation record; customers need to understand what changed in their day-to-day work.
Here is a complete example of how to make that translation.
The merged pull requests
Imagine a SaaS team is preparing its weekly update. These three pull requests were merged:
| PR | GitHub title | Technical summary |
|---|---|---|
#412 | Add persisted filters to customer list | Stores filter state and selected columns per user |
#417 | De-dupe account-owner notification jobs | Prevents repeated events from enqueueing duplicate work |
#421 | Move CSV exports to async worker | Generates larger exports outside the request cycle |
All three are real candidates for a changelog, but not as written.
The weak version: a copied development log
## Updates
- Added persisted filters to customer list.
- De-duped account-owner notification jobs.
- Moved CSV exports to an async worker.
This is technically accurate, but it leaves the reader with three questions: What changed for me? Where should I look? Why is this worth my attention?
The customer-facing version
# Customer operations are easier to return to and export
## Save the customer views you use most often
You can now save the filters and columns you rely on in the customer list. Build
a view for priority accounts, trials, or a specific owner, then reopen it without
setting it up again.
## Fewer duplicate account notifications
Account owners should now receive fewer repeated notifications for the same
event, making it easier to focus on the action that needs attention.
## More reliable exports for larger lists
Large customer-list exports are now prepared in the background, so you can keep
working while the file is generated.
The customer-facing version does not overstate the work. It simply converts each implementation detail into an observable outcome.
Why this version works
| Source material | Customer-facing decision |
|---|---|
| Persisted filter state | Name the reusable view, not the storage mechanism |
| Notification-job de-duplication | Describe the interruption customers will stop seeing |
| Asynchronous processing | Explain that people can continue working during the export |
The headings are also useful in a public changelog, email digest, or in-app widget because a reader can decide in seconds whether the update matters to them.
A repeatable PR-to-changelog method
- List the merged PRs in the release window.
- Remove work that is internal-only, reverted, or still hidden behind a flag.
- Group related PRs by the customer job they affect.
- Write a headline around the customer outcome.
- Check the wording with the engineer or product manager who owns the change.
- Publish the approved update from one source of truth.
Use the GitHub release notes templates when you need a starting structure, and read how to generate release notes from GitHub pull requests for the complete workflow.
Changelog Generator starts with the merged PRs, creates an editable customer-facing draft, and gives your team a hosted place to publish the final update.
Create your next GitHub changelog from merged pull requests.