Cc'ing this here too (from #fossmaintainers:
matrix.org, #hledger:
matrix.org, #hledger:libera.chat ...)
I'm editing the changelogs and it's always a pain. I have automated it a little. hledger's changelogs (and then release notes) are based on commit messages. `./Shake changelogs` does some useful initial content gathering (
https://github.com/simonmichael/hledger/blob/master/Shake.hs#L631). I can run it repeatedly to incrementally add interesting commit messages to the proper CHANGES.md files in the right format. This is a great start but the final editing and historical research is still too much. It feels inefficient.
Problem 1: Without good clear changelog-ready commit messages, it's a lot of work to reconstruct the context and clean them up at release time, since a lot of time has passed.
We try to reference issues in commits, but fairly often it's missed. Yesterday I had to find the context by searching for commit hashes on github several times, I'm wondering about automating that. Then I've got to digest the issue, which often takes a bit of effort; but at least it's detailed.
Problem 2: Getting changelog-ready commit messages is a lot/probably too much to ask of most contributors. Many hledger contributors are first time or infrequent. I feel that adding this to the things I ask of them will just drive many of them away.
I could add messages myself at merge time if using squash merges, or regular merges. But not when using rebase merges (our common case), unless I alter contributors' commits, which seems awkward.
The ideal would be to stay on top of this throughout the release cycle. Eg, every merge is required to include a good changelog entry. Or, changelogs are updated and brought to release readiness weekly.
hledger's docs are quite important to me and I'm heavily involved in producing them. But if the right person wanted to serve as changelog tsar, that could be another way. (Throw more human power at the problem.) Even so, I think some automation is almost a necessity to produce good results.