Comment by steerablesafe | Hacker News Reader

Comment by steerablesafe | Hacker News Reader

Parent Full thread

It feels like a missed opportunity of more automation, TBH. Notice that each commit mentions one or more bugs, probably enforced by commit hooks.

What about dropping the ones that don't fix bugs (assuming they are part of ongoing work), replace the ones that fixes the bug with the description of the bug (and a working link!), and categorize them based on the tags of the bug (defect, feature request, etc...) so you would automatically get a list like:

   New Features:
     "title of feature request 1"
     "title of feature request 2" 
   Bugs fixed:
     "bug1"
     "bug2"

The Release Notes are organized by PR and you can use configuration to sort into sections based on labels on those PRs. You can also ignore labels / particular users. So in theory everything you are outlining here is possible

https://docs.github.com/en/repositories/releasing-projects-o...

> in theory everything you are outlining here is possible

I think part of the problem is also that in theory, it's already possible to write a good changelog as well — but of course, what's relevant is what happens in practice :)

Even then, in a commit message/PR description I (as a contributor) expect to read the origin/big picture of the bug, how it was discovered/narrowed down, references to where it was introduced, what other solutions were tried — those kinds of things. Those aren't relevant to users though.

Reply on news.ycombinator.com