You might say I learned this lesson as a technical writer, too.

If you’re publishing release notes (and you really should), it’s for things that have gone through QA. Ask your testers to provide the first draft of the release notes, then ask them to verify the final draft. This has two benefits:

1. If they can’t explain something, I don’t think they understood it well enough to test it.

2. Having a draft from the QA will help technical writers understand what happened. And if they still get it wrong, that’s fine – the QA should catch it in their review of the final draft.

The first draft should be a simple summary attached to the bug or feature in the tracking system. It’s not supposed to be well written or be clear to laymen; that’s the writers’ job. But it’s supposed to explain what happened, and why, and it should be detailed enough to paint the full picture for the reader.

There’s an added bonus here, which is that the first draft will remain in the bug tracker for future reference; this matters more if your release notes are not entered into the tracker, meaning whatever the QA wrote is the final word. Six months later when you’re trying to understand what the big idea was, a badly written release note will seem like a million dollars.