To auto-draft a changelog from merged pull requests, set a rule that watches a branch (usually main) and, if you want, a PR label. When a matching PR merges, your changelog tool creates a draft entry. In FeatureOS the draft also carries the feedback posts linked to that PR, and it is never published automatically: you edit the wording and publish.
Why draft from PRs but not publish from them?
PR titles are written for developers ("fix: debounce search input"). Customers need "Search no longer lags while you type". A generator can collect what merged, but a person should decide what is worth announcing and how to say it. Drafting removes the blank page; reviewing keeps the voice. For open-source generators that work from commits and tags, see GitHub changelog tools compared. For writing the entry itself, see how to write release notes.
What a changelog rule contains
- Base branch. Only PRs merged into this branch count, for example
mainorrelease. - PR label (optional). Only PRs with this label count, for example
user-facing. This filters out refactors and dependency bumps.
When a PR matches, FeatureOS creates a draft changelog and attaches the posts linked to the PR, so the entry already points at the requests it answers.
Set it up
- Connect GitHub in Organization Settings > Integrations > GitHub (details) and accept the updated GitHub permission.
- Link PRs to feedback posts, manually or with the post URL in the PR description.
- Add a changelog rule with your base branch and optional label.
- Label user-facing PRs. Merge as usual.
- Open the draft, rewrite the headline in plain language, and publish.
Tips
- Use one label for "customers should hear about this". It is the cheapest filter.
- Skip the rule on branches that merge dozens of PRs a day unless you filter by label.
- Publishing notifies the voters on the attached posts, which is the point.
Availability note: this needs an updated GitHub permission (pull requests, read-only). An admin accepts it once in GitHub; existing issue linking is unaffected.
