> I don't expect end-users of most open source software to be satisfied with either the high-level nature of commit titles, or their minutia. In my experience,

> I don't expect end-users of most open source software to be satisfied with either the high-level nature of commit titles, or their minutia. In my experience, they aren't. They want a top-level view of why/if they should upgrade. In my dayjob, when preparing a release, we use tools to dump the git commit messages into the head of the CHANGELOG, then edit it back into user-facing text. We omit changes that are not user-facing (eg. 'gem you've never heard of upgraded to 0.4.4') and focus on changes they care about (eg. 'Redact credentials from URLs in a cached buildpack's output'). See for example our Ruby buildpack CHANGELOG[0]. We build our own binaries for buildpacks. So in addition, for our Github releases, we take the CHANGELOG entry and append a table of supported binaries and default versions[1]. These show up in the CHANGELOG only if we add or drop a core binary. We work out of Tracker, so we link to Tracker stories, bugs and chores for every mentioned in the CHANGELOG or release notes. [0] https://github.com/cloudfoundry/ruby-buildpack/blob/master/CHANGELOG https://github.com/cloudfoundry/ruby-buildpack/blob/master/C... [1] https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.6.22 https://github.com/cloudfoundry/ruby-buildpack/releases/tag/...