Anyone who wants their commit titles to be less like document headings and more like parseable data structures is going to find it difficult when their peers don’t play along.
To that end you will want to provide a validating parser and then start rejecting commits whose messages don’t validate. If your validator has even one or two bugs you’re going to see all goodwill evaporate, and for what? So that you could read:
bug(fix)[8177] Add missing paren
instead of Add missing paren
…
Fixes http://bugs.com/8177
Commit messages are the primary source of why you did something. Focus all of your energy on writing clearly, concisely, and compellingly, and helping others to get better at doing so. Working on anything else is wasted energy compared to the importance of honing written communication skills.
I like to follow conventional commit style, and some repos I work on have CI checks for it. It's been fixed now, but for a long time the validator we were using would reject commits that included long urls in the body (for exceeding the width limit).
It was enraging - I'm trying to provide references to explain the motivation of my changes, all my prose is nicely formated, but the bulleted list of references I've provided is rejecting my commit.
I generally think it's in the category of a social problem not a technical problem - communicate the expectations but don't dogmatically enforce them