3 ms·
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 dr
by steerablesafe 5y ago
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"
- Vinnl 5y agoEven 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.
- mylesborins 5y agoThe 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-on-github/automatically-generated-release-notes#example-configuration https://docs.github.com/en/repositories/releasing-projects-o...
- Vinnl 5y ago> 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 :)