or you can say something equivalent yet unambiguous

A good commit message isn't about convention, and no convention makes a commit message good.

When I review a commit, I need only the information I won't get from the diff that I need to understand the context and the behavior.

My brainpower is a limited resource and extra noise in my signal is extra work.

I'm totally here for `ISSUE_123456 fixes defect` and `wip` are insufficient, but I'm not writing a code blog post in there.

At my work we almost encourage the blog post in there idea.

It's not a hard and fast rule and it's ok to ignore it when it makes sense. But we also don't mind if your commit message takes longer to write than the code took to change and debug.

A lot of context is assumed in commits, and almost all of it is temporal. Capturing as much of that as possible pays off down the line.

Commit in the article is a good example where the context explains much more than the change.

(On the flip side, the pay off has an expiry date so I'm not extremely fussed when people lax, but it's still good to check in basic assumptions whith your code)

I fix about 2~4 issues by day, 20~40 commits by day. If I do write a blog post for every commit my productivity will down by 70% at least.

Well that's the argument about immediate productivity and good documentation.