I write the changelog for a product. In fact I write two changelogs - one for engineers and one for customers.
Engineers:
- [New Feature] Added ability to ___
- Improved logging on ___
- Fixed a memory leak on ___
Users:
- [New Feature] Added ability to ___
Not every change can be explained in one sentence to users. Internal logging? Memory leaks? You're speaking a foreign language. Those entries must be thrown out when making the changelog for users.
Eventually, there comes a release when you have thrown everything out. What do you write? "Bug fixes & enhancements".
So we create our change log (they are part of our 'release notes' actually) with only the user in mind but we reference the bug tracker number next to it.
This is what we check in to the 'source' for the release notes.
Then when we post to the 'outside world' we just remove those tracker numbers (takes a few seconds).
That way the engineer can see the 'easy to understand conceptually' bug fix/enhancement and if they want to know more then they can see the Tracker reference and go and look up the 'real meat - with all the discussion and threads etc.
For those bug fixes that we 'don't' document we have our source code software.
We maintain a CURRENT_CHANGES.md with those sections. When we do a release, we move the contents of CURRENT_CHANGES to a new entry in RELEASE_NOTES.md.
One of these days, I will get around to writing something that displays RELEASE_NOTES in the app, without the Internal section
- Fixed flickering lower-right pixel when hovering over close button with a stylus on devices with more than 300 % UI scaling applied.
- Fixed alignment issue in About dialog.
- Improved help text for Gizmo frobbing feature.
To me a changelog should prominently document changes in function and behaviour. I don't particularly care if an exception message got a typo fixed, but I do care about a new feature, if a login problem for a subset of users has been resolved or a crash under weird circumstances has been fixed.
I must be a crazy user, because I generally like reading through changelogs to see if an update is worth applying because it addresses a specific issue I am having, implements a new interesting feature I want to try, or fixes critical flaws.
Luckily, though, public bug trackers are generally a good way to find out at least the 'is my bug fixed' part without the changelog (your issue is closed as 'fixed in X.Y')