>I know you're writing in agreement, but it sounds like your changelog is an intermediary step, and I don't understand why it's needed? To fill in the gaps from lazy commit messages?
It's about the audience.
* Commit Messages - These are comments that last for the life of the project. The audience in for engineers far in the future and it should explain what changed, why and the context
* Pull Request Message - These are comments that live for a short time and are targeted for reviewers. Things you might cover here that aren't covered in a commit message is what kind of manual tests were done, releases you want to target, or reference other PRs that might be related
* Changelog entry - These audience here is internal. It is SREs, release managers and the authors of the release notes
* Release notes - This is for the customers
For many changes, all of these can be the exact same thing. It's one reason why I like conventional commits. In those cases you can write it once and it shows up everywhere with very little friction. You add it to the commit message, then when you open the PR the title and body are populated from the commit. When you generate changelogs, it is pulled from git history. Engineering isn't always the happy path, for special situations in each one of those steps you can edit it and add or remove context for the particular audience.
Not all orgs need this or need to care about it. It's completely okay if they don't. I've just found it useful in mine.
It's about the audience.
* Commit Messages - These are comments that last for the life of the project. The audience in for engineers far in the future and it should explain what changed, why and the context
* Pull Request Message - These are comments that live for a short time and are targeted for reviewers. Things you might cover here that aren't covered in a commit message is what kind of manual tests were done, releases you want to target, or reference other PRs that might be related
* Changelog entry - These audience here is internal. It is SREs, release managers and the authors of the release notes
* Release notes - This is for the customers
For many changes, all of these can be the exact same thing. It's one reason why I like conventional commits. In those cases you can write it once and it shows up everywhere with very little friction. You add it to the commit message, then when you open the PR the title and body are populated from the commit. When you generate changelogs, it is pulled from git history. Engineering isn't always the happy path, for special situations in each one of those steps you can edit it and add or remove context for the particular audience.
Not all orgs need this or need to care about it. It's completely okay if they don't. I've just found it useful in mine.