Why we publish a changelog
Every user-visible change to ContentCrew goes on a public page the day it ships. Here is what that gets you.
Most tools tell you what changed when they want something from you. A release email lands, it lists three features, and the other forty things that moved that month stay invisible. You find them by accident, usually when a button is somewhere new.
We publish the changelog instead. Every user-visible change goes on that page the day it ships, in plain language, with the date attached.
What you get from it
You can see whether the thing you asked for is done. If you told us that approvals were slow on mobile, you do not have to email and ask — you check the page, and the answer is there with a date next to it.
You can also see the shape of the work. Read a month of entries and you learn where we are spending our time: the reporting layer, the drafting tools, the calendar. That tells you more about where ContentCrew is heading than a roadmap does, because it is a record of what actually happened.
And you can plan around it. When a change affects how your crew works — a new approval step, a different publishing window — you read it before someone on your team runs into it.
What goes on the page
Anything you can see or use. New features, changes to existing ones, fixes for things that were broken. Internal work stays internal: if a change does not alter what you do inside the product, it does not earn an entry.
The entries are short on purpose. One or two sentences, what changed, what it means for you. If you want more, the feature pages go deeper.
Start with the changelog itself. It runs newest first, and it is current as of today.