Features / Product feedback
Changelog
Tell them it shipped
Release notes that go out to the people who asked for it, drafted from the fix that actually shipped, then sent once a human approves the wording.
What it does
- Public changelog page and an in-app feed
- Drafted from the change that shipped, not written from scratch
- A human approves the exact wording before anything sends
- The people who reported it are told, without anyone remembering to
Without it
You shipped the thing they asked for and never told them
You shipped it and nobody told them
The fix went out on Thursday afternoon. The four people who reported it are still waiting, because telling them was a manual job that was on nobody's list.
Release notes written from memory on a Friday
Someone opens a blank page and tries to reconstruct the week from a commit log written for engineers. It takes an hour, it misses two things, and one line describes a change that got reverted.
The thread that never closed
Support said they would let the customer know when it was fixed. Six weeks later the customer writes back to ask whether anyone ever looked at it. It was fixed in week two.
How it works
An entry starts from the merge, not from a blank page
Hand Tore a merged pull request and it drafts the entry from it: the title cleaned up, the category read from the commit prefix, and the repository, pull request number and commit kept on the record. The draft already knows what changed, so you are editing rather than remembering.
What that includes
- Hand Tore a merged pull request
- the repository
- pull request number
- commit kept on the record
One pull request can only ever produce one entry
That is a uniqueness rule in the database on the organization, the repository and the pull request number, not a check the drafting code has to remember to make. Run the same merge through twice and you update the draft rather than creating a second one.
Announcing it is a human action, in the code itself
The broadcast path refuses any actor that is not a person holding the notify permission. Not a policy in a document, and not a prompt the model is asked to respect. A check that throws before anything is queued.
Nobody is told twice, even after a failure
One send record per recipient per channel, enforced by a unique constraint rather than by the sending code being careful. A retry after a partial failure cannot turn into a second email to somebody who already got one.
What was sent is recorded, and checked again on the way out
Each send stores the exact text and a hash of it. The hash is recomputed at delivery, and a send whose text no longer matches its hash is suppressed rather than delivered.
What it means for you
The person who reported it hears from you
Not a broadcast they have to scan for their issue. The specific people whose conversation is behind that fix, told that the thing they wrote in about is done.
Release notes stop being a chore you skip
The starting point is the work that actually shipped, with the commit attached. Editing a draft that already knows what changed is a different job from remembering the week.
You can prove what was sent
Every send is recorded with the exact text it delivered and a hash of it, so a question about what a customer actually received has an answer rather than a best guess.
The honest limit: Drafting from a merge has to be handed the merge. There is no GitHub webhook wiring it up yet, so something has to tell Tore that a pull request landed rather than Tore noticing on its own. Approving and publishing an announcement is also not yet an action you can take in the product, which is why this page describes what the record keeps rather than a button you press.