Link entries to the requests they close
In the entry editor, add the posts the release resolves under Posts this ships; Looph also suggests posts that look related. The public entry lists them under This update covers.
When you publish, Looph offers to mark those posts Complete and to tell the people following them that something they asked for has shipped, with one message each listing what they asked for, by email and in-app. This is the whole reason to run feedback and changelog in the same tool: the notification is part of publishing rather than a task someone forgets.
Who is told when an entry publishes
Tell people it shipped reaches the followers of the posts the entry ships. People follow a post automatically when they write it, vote on it or comment on it, and anyone who is signed in can follow a post by hand with Subscribe. Followers of a duplicate that was merged into a linked post are told as well.
Each person gets one message per publish, naming every linked post they follow. Looph checks each person against the post's board at the moment of sending, so someone who can no longer see a private board is not told about its posts, and you are never told about your own release. A person hears about a post once: if an earlier entry already told them it shipped, a later entry that links the same post leaves them out, and the dialog says how many were told before.
The message arrives by email and in-app, and as a push notification for people who turned push on. People who have turned off both email and in-app notifications for it are skipped. Your teammates hear about the entry separately: every workspace member gets a notice that it was published, except members who follow a linked post, who get the shipped message instead.
Write for the person who asked
Lead with what changed and who it affects, not with the internal epic name. Two sentences that a customer understands beat a bulleted list of tickets.
Distribution
Each workspace's changelog has a public page, with a page per entry, and an RSS feed. You can embed a read-only copy of the changelog in your own site, and a Slack subscription can post each published entry to a channel if you tick that event. Publishing also sends the changelog.published event to your webhooks.
Each entry can have a type, New, Improved or Fixed, and an optional free-text category. Announcing entries inside your product through the in-product widget is coming soon.
A release, step by step
Publishing is where the loop closes, so it is worth doing in the same order every time.
- 1Open Admin, then Changelog, and start a new entry.
- 2Write the entry for the people who asked: what changed and who it affects.
- 3Choose a type: New, Improved or Fixed.
- 4Add every post the release resolves under Posts this ships.
- 5Choose Publish, and in the dialog choose whether to mark the posts Complete, tell their followers it shipped, and comment on each post.
What the Publish dialog checks
Before anything is written, the dialog counts what the release will do: how many posts it ships, how many people follow them and how many posts move to Complete. Publish stays disabled until the counts load. Every option starts ticked, and you can untick any of them for this release. An entry with no linked posts publishes straight away, without the dialog.
Marking posts Complete needs the Triage feedback permission; without it the dialog says the statuses stay as they are, and followers are still told. A post that is already Complete is not moved, a Closed post stays closed but its followers are still told, and posts awaiting approval, rejected or deleted are listed as skipped.
Comment on each post adds one comment as you, which notifies nobody, including anyone you @mention. It starts as This shipped! Read the update, followed by the entry's link. You can edit it, but it must keep that link, stay under 5,000 characters and pass your workspace's word filter. Posts on an archived board, posts you cannot see and posts this entry has already commented on get no comment.
Emails cannot be recalled once sent. Above 500 people, delivery is spread over the next few hours, and the editor header shows progress, such as Telling 1,200 people — 400 told, then Told 1,200 people with the date. If a Zap runs on publish, the dialog reminds you to untick Tell people when that Zap already emails requesters.
Writing, publishing and deleting entries, drafts included, needs the Changelog permission. The owner always has it, admins have it unless the owner turns it off, and members have it only when the owner grants it in the Roles tab.
Drafts and corrections
Save draft keeps an entry private until you are ready. Entries publish at the moment you choose Publish; there is no scheduled publishing. If you publish by mistake, Unpublish takes the entry down and can put the posts' statuses back.
Unpublishing, republishing and late links
Unpublish asks Move to draft? and hides the entry from the public changelog until you publish it again. Tick Move posts back to their previous status to undo the Complete step; only posts nobody has changed since go back, and otherwise they stay Complete. Comments posted on the linked posts stay, and messages already sent cannot be recalled.
Publishing the same entry again offers to tell its followers again, including the people it told the first time, and the dialog says when they were told. The changelog.published event that your webhooks, Slack and Discord receive is sent once per entry, so a second publish does not send it again.
If you add posts to an entry that is already published and save, Looph asks whether to tell the people behind the newly linked posts, mark them Complete and comment on them. Nobody who was told before is told again. Not now keeps the links without telling anyone, and the next save that adds a link offers it again.
An entry can ship up to 50 posts. With no search, Add posts suggests posts that are Planned or In progress first, then Under review and Open, most-voted first. Once an entry is published its URL slug is locked, because people may already have shared the link; move it to draft to change it.
Changelog entries versus release notes
Release notes list what changed in a version, for people who need the detail. A changelog entry tells a customer that the thing they cared about now works, in the words they would use. Both are useful, and they are different documents: write release notes for completeness and changelog entries for the people who asked.
A good test for a changelog entry is whether a customer who never opened the product's settings would understand it in one read. If it needs a ticket number or a component name, it is a release note.