A feature can be deployed and still be unavailable to most customers. Announce it as ‘available now’ without explaining who has access, and an otherwise polished release note becomes misleading.
Release notes explain changes delivered with a software update. Reviewing them means checking the claims behind the wording: what has shipped, who can use it and whether the instructions match what readers will encounter.
Assign an evidence source and reviewer
Give each significant claim a supporting source and someone responsible for confirming it. A useful division is for engineering to check deployment, quality assurance (QA) to verify tested behaviour, and the product team to confirm eligibility. One person might cover several responsibilities in a smaller organisation.
Agree technical meaning before polishing sentences. When contributors are developing their IT English, explain in review comments why ‘deployed’ and ‘available to customers’ are different claims, rather than silently swapping terms.
Keep references to deployment records, test results and agreed product decisions alongside the working draft. These internal review aids give reviewers something concrete to consult; include them in the published notes only where appropriate for readers.
Confirm deployment and user access
Verify the release identifier and timing against the actual deployment. Treat a completed development ticket as a starting point for the review, then establish what reached the live product and when.
Access needs a separate check. Confirm relevant conditions, including subscription tier, account permissions, application version, platform and rollout stage, with the person responsible for enabling the feature.
Suppose a new export feature is enabled only for pilot accounts. An announcement to all customers needs to identify that audience. Confirm the current rollout status with the release owner, and get agreement on any completion date before presenting it as a public commitment.
Put restrictions beside the affected change, where readers can judge whether the announcement applies to them without searching another document.
Check the scope of fixes and limitations
Match each fix description to the behaviour QA verified, including the affected version, test conditions and remaining exceptions. Keep the claim within that evidence: successful testing of one failure case supports a statement about that case, rather than every related problem.
Words such as ‘all’, ‘always’ and ‘fully resolved’ deserve particular scrutiny. Ask the reviewer to confirm their scope or narrow the wording.
Check known limitations against the same release and confirm that any workaround remains valid, including whether it applies before or after updating. Give limitations that could affect a reader’s decision enough prominence to be noticed alongside the benefits.
Have security-related details cleared through the organisation’s disclosure process before publication.
Verify instructions from the reader’s position
Follow the documented steps using the intended reader’s permissions in a suitable test environment. Testing solely through an administrator’s account can conceal restrictions that other users will encounter.
Check menu names, buttons, prerequisites and linked guidance against the released interface. Screenshots should show what the relevant audience will see. Where supporting documentation is awaiting publication, confirm that the destination will be accessible when the announcement appears.
For compatibility changes or removed functionality, establish who must act, what they need to do and the deadline. The instructions and dates should agree across the release notes and supporting documentation.
Then give the update to a colleague outside the drafting team, without explaining it first. Ask them to identify whether it applies to them, what changes and whether action is required. Their answers can expose missing information that a sentence-level edit would overlook.
Approve, publish and correct
Keep approval proportionate to the release. A routine correction might need the relevant technical reviewer and editor; a change affecting access or compatibility warrants the people responsible for those decisions.
Record approval against a specific draft. Assign one person to publish that version and check the live page. Subsequent edits to availability, scope or instructions need renewed confirmation, even when made during the final copy-edit.
Resolve claims that could mislead readers before publication, either through confirmation or removal. If removing an unresolved claim would leave the announcement misleading or materially incomplete, hold publication until the facts are settled.
After publication, distinguish a change in circumstances from an original error. Update rollout information as availability changes. For a material factual error, add a dated correction explaining what changed and notify affected readers if it could influence their actions.
David Prior
David Prior is the editor of Today News, responsible for the overall editorial strategy. He is an NCTJ-qualified journalist with over 20 years’ experience, and is also editor of the award-winning hyperlocal news title Altrincham Today. His LinkedIn profile is here.
