Who writes the release notes? Changelog ownership that survives growth

Search any dead changelog on the internet and you’ll find the same tombstone: a last entry from fourteen months ago, sitting above a product that has visibly shipped since. The changelog didn’t die because the team forgot how to write — the entries above the gap are usually fine. It died because nobody owned it. Someone left, or got busy, or a reorg moved the person who cared, and there was no name attached to the job. Craft problems make changelogs bad; ownership problems make them stop. This guide is about the second failure — who writes the notes, who edits them, who presses publish, and how those answers change as a team grows.

“The team owns it” means nobody owns it

The first rule is the one teams resist longest: changelog ownership is a name, not a group. “Engineering owns the changelog” is how you get a changelog that everyone assumes someone else updated. Diffuse responsibility fails quietly — no alert fires when an entry doesn’t get written, so the only defense is a specific person who notices the gap because it’s their gap.

The owner is not necessarily the writer. Owning the changelog means being accountable for three things: every user-visible change gets an entry, entries meet the bar (reader-first, symptom-named, dated), and they ship on time. Whether the owner drafts every word themselves is a separate question — and at any team size past one, the answer should usually be no.

The split that works: facts from the shipper, voice from the owner

There are three common ownership models, and each fails in a characteristic way when it runs alone:

Engineers write everything. The person who shipped the change has the facts — what broke, what’s different, what to do about it — and nobody else does. But left unedited, engineer-drafted notes drift toward diffs: internal service names, ticket numbers, causes instead of symptoms. Accurate and unreadable.

Product or PM writes everything. Reader-focused, consistent — and chronically late, because the writer hears about changes secondhand. Bug fixes vanish (nobody told the PM), and technical detail gets fuzzy exactly where precision matters most: breaking changes and migrations.

Marketing writes everything. Polished, on-brand, and allergic to bad news. Fixes read as confessions, so they disappear; every entry trends toward a mini press release. Marketing voice belongs on tier-1 launches, not on the Tuesday fix stream.

The model that survives contact with a real release schedule is a draft-and-edit split: the person who shipped the change drafts the entry (they have the facts and the context, and they have both right now), and one named owner edits and publishes (they hold the voice and the reader’s perspective). The draft is allowed to be rough — two honest sentences from the engineer beat a polished paragraph reconstructed by someone else a week later. The edit pass is where internal names become things users can see, causes become symptoms, and the entry gets checked against a template. A style sheet is the contract between the two roles: six rules on a page, so the editor is enforcing something written down rather than personal taste.

When it gets written: at merge, not at release

Most missing entries were never skipped on purpose — they evaporated in the gap between shipping and writing. The fix is to move the writing to the moment of maximum context: the entry gets drafted when the change merges, by the person merging it, while they still remember what the user-facing effect is. At release time, the owner’s job is editing and sequencing a queue of drafts, not archaeology.

Make the decision explicit in the workflow you already have. A single line in the pull-request template does more than a policy document:

## Changelog
<!-- One or two sentences, written for a user. -->
Entry: …
— or —
No entry needed because: …

The second option is the important one. “No entry needed because it’s an internal refactor” is a fine answer; silence is not an answer. When skipping requires a stated reason, skipping stops being the default — and the reviewer of the PR becomes, incidentally, the first reviewer of the changelog. Teams that run changelog automation in CI can wire this straight through: the merge drafts the entry, a human publishes it at release. The same draft-then-publish rhythm handles trains and staged rollouts — write at merge, publish when users can actually touch it.

The review loop (keep it short)

One edit pass is a quality gate; three approval steps is how notes ship four days after the release they describe. The editor’s checklist is short: does the first line answer “what changed for me?”, is the fix named by its symptom, is anything breaking flagged loudly with a date, does the entry link somewhere useful? Two reviewers earn a standing invitation without becoming blockers: support, who can read a draft and tell you which sentence will generate tickets (and which ticket-generating change you forgot to mention), and — for entries with contractual or compliance weight — whoever owns those words. For everything else, the owner publishes without a meeting. A changelog that needs sign-off from four people is a changelog that will quietly stop existing; if an entry is wrong, edit it — the same discipline as hotfix communication, where the first version ships fast and gets refined in place.

Ownership by team size

Solo founder: you are all three roles, and your enemy is friction, not coordination. Bolt the changelog to an existing ritual — the entry gets written when the deploy script runs or the tag gets pushed, ideally seeded from the git log and edited into English. If it isn’t part of shipping, it will lose to shipping.

2–10 people: this is where changelogs die most often, because “everyone knows what shipped” stops being true just as “nobody owns comms” is still true. Name the owner now — usually a founder or the most reader-empathetic engineer — and adopt the PR-template line. Rotation (“release captain writes the notes”) can work, but only with a style sheet and a stable editor; rotating the drafting is healthy, rotating the accountability is how gaps start.

Bigger: ownership professionalizes — a PM, docs writer, or product marketer owns the public stream, engineering feeds it through the merge-time pipeline, and the internal changelog becomes the raw material the public one is curated from. The failure mode changes too: not gaps, but drift — the public changelog slowly becoming marketing while the real changes hide internally. The fix is the same name-not-a-group rule, applied to the boundary: one person decides what the public stream owes its readers.

Six anti-patterns

The quarterly archaeology dig. Nobody wrote anything for three months; now someone reconstructs “what shipped” from the git log and a haunted look. Batch-written history is always thinner than write-at-merge truth — and readers can tell. (If you’re digging out of an old gap, do it once, honestly — backfill rules here — then fix the process.)

Assigning it to the newest person. The intern-owns-the-changelog model treats the job as typing. The writing needs the least context of anyone on the team exactly where context is the whole job.

The approval gauntlet. Legal, brand, two directors, then publish — a week late. Reserve heavy review for the entries that carry risk; let the fix stream flow.

The marketing rewrite that deletes the facts. If the edit pass removes version numbers, dates, or the word “broken,” it’s not editing anymore. Voice is negotiable; facts are not.

Publish-access-for-everyone, editor-for-no-one. Twelve authors, twelve registers, no bar. Everyone can draft; one person publishes.

The changelog as performance review. When entries exist to make teams look busy to leadership, they optimize for volume and internal effort — the opposite of what a reader wants. Keep status reporting in the internal stream; the public changelog answers to users. (And judge the process by reader-side metrics, not entry count.)

How this maps onto Wakelog

Wakelog is built for exactly the draft-and-edit split. Anyone who ships can draft from where they already work — wakelog post --draft in a deploy script, a curl from CI, or the web form — and drafts stay invisible until the owner reviews and publishes them (or schedules them with publish_at to land when the rollout does). The API means drafting lives inside the shipping workflow instead of in a separate tool someone has to remember to open. One honest caveat: Wakelog has no roles or per-user permissions — a project is a single account, so the publish gate is a working agreement, not an enforced one. For a team small enough to share a token, that’s the same trust that already ships your code.

Start your changelog — free   Next: one voice with many authors →

Related guides

Last updated 2026-07-30 · All guides