CI checks are overly nitpicky about descriptions.

[jaraco]

In #505 (comment), I encountered a nitpicky check. It seemed to be insisting that I add a body to the change description. Some changes, such as adding a changelog entry, really need no elaboration, and I'm not about to start littering the descriptions with meaningless drivel to satisfy a linter. Please disable or make this check more lenient, or at least provide some guidance on how to generate content for the body.

[webknjaz]

It checks for the best practices by default. Particularly, these: https://cbea.ms/git-commit/.
It is helpful but I recognize that many people don't know how to write good commits so I've deliberately put the check into a separate workflow that is non-voting (not required for merging PRs).

It is supposed to be annoying but I think it's a good idea to add some links to the job summary from my articles collection, and maybe some more words...

It's also useful to have the gitlint plugin integrated into one's editor of choice where they write commit messages (since it's the earliest point when the messages can be corrected).

In CI, the check only runs on PRs since it's pointless to report failures after the commits are already in the main branch. So it does attempt to let people, who care about this stuff, improve their commit messages while remaining non-invasive.

By the way, the job summary output is supposed to be easier to consume: https://github.com/cherrypy/cheroot/actions/runs/5032348262#summary-13629108128.

P.S. Obviously, the maintainers aren't expected to always fix such linting violations from other contributors. I wonder if it'd be useful to make the automation react to a label like give-up-on-nice-commits. Though, having the error visual may hint to the merge actor that maybe they need to select a "squash" option and write one nice message rather than using a real/natural merge commit.