“Have you linted and unit tested your commit message?”
“Junior Developer wanted. 10 years of Conventional Commits experience required.”
“Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)”
Something tells me the authors are hard at work solving a problem nobody needs solving.
I share some of your sentiment though: I feel like the biggest reason to enforce a style like this is not for "machine readable commit messages" (I mean, why?), but to encourage people to split refactors and features in separate commits. This makes it easier to understand what's going on later.
I think this site should've begun with that, and left the spec as a footnote.
It's usual to include the ticket id in the commit or PR so you can pull it from logs at build time and have a canonical list. Then grab the info to include from the ticketing system.
Except when people would literally just mash their keyboard like this:
Commit 1234: iuadiuasdbuidawbiywbuqbqbdfpbdpiube
The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).
Patch descriptions are for developers, not for users -- aside from the fact they're the wrong granularity (no user cares if it took 20 patches and three PR cycles to implement a feature), they should contain details and justification that are only useful for future debugging or for review purposes (which users also don't care about). And if you have a bugfix for a previously-merged patch that hasn't yet been released, why would you include the bugfix in the changelog?
Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.
Common practice for a long time has been to include a ticket id in the commit and then use a script to pull all the ticket ids from the commits since the last release and pull the (user facing) release note info from ticketing system.
Of course you don't want commit messages going to users but you don't want to rely on handcrafted lists either. Particularly when a release as far as a customer is concerned is infrequent and contains changes from many repos.
We can, and do. Knowing that the merges are going to wind up as items in the changelog leads us to size and structure them accordingly, or at least make a best effort to. The end result is a changelog where most PRs are somehow "noteworthy" and the ones that aren't (usually "chore" type in Conventional Commits lingo) can all be grouped together down the tail end.
The point isn't to produce a perfect result, but one that is "good enough". With this system, the friction to produce a new release is so low, and we have so many projects, that we can easily push out a steady stream of releases at very low cost with this approach. And following the pattern across all the projects has been great for consistency, compared to the relative chaos in patterns and procedures that we had before.
We use this in our lerna monorepo and it works like a charm as the CI can just bump whatever packages based on the paths and commit messages.