He says Conventional Commits buried the one field that matters under the one that doesn't

A whole essay about which side of the colon the scope goes on

Sumner Evans' post argues that Conventional Commits — the fix(scope): description format that spread out of the Angular ecosystem — optimizes for the wrong thing. It drew 285 points and 220 comments, and the thread is a near-perfect split between people who think it's bikeshedding and people who think the bikeshed is load-bearing.

Scope first, because that's what everyone actually reads

Evans' core move is to ask who reads a commit log and what they need. He names three groups — contributors tracking changes in their area, debuggers hunting commits that touched a component, incident responders scanning recent changes during an outage — and argues all three want scope before type. Conventional Commits inverts that: type is mandatory and leads the line, scope is an optional parenthetical. He'd rather write subsystem: description, the format Linux, Go, Git, FreeBSD and nixpkgs already use:

• Linux: i2c: virtio: mark device ready before registering the adapter
• Go: net/http/cookiejar: add godoc links

He then dismantles the spec's "promises" one by one. Automated changelogs conflate two audiences with incompatible needs — "a changelog is user-facing" about functional differences between versions, while "a commit log is developer-facing" about how the code changed. SemVer automation breaks on reverts, accidental breakages, and retroactive un-breakages. The type-driven build triggers, he argues, are a mild security footgun.

The reviewers and CI crowd push back

The sharpest dissent comes from people for whom type-first is a feature, not a bug.

"As a reviewer, I love type first because it sets expectations for what I'm going to look at. Similar if I'm bisecting or doing other history operations." — a maintainer who reviews by type

"The type of the commit informs the automated workflows how to handle the commit. This is why it comes first… a bunch of fix: only bumps your patch version, a feat: bumps minor, feat! major." — a head of engineering on CI/CD automation

And the unglamorous case for any convention at all: most teams don't write good messages unprompted.

"Is it theoretically possible that people can write good commit messages without a framework? Yes. Does that work out in practice across entire teams? No. Any kind of a convention for commit messages is an improvement." — a developer who's watched it fail in practice

The agreers want the issue ID, not the type

The people who side with Evans mostly do so for a reason he barely covers: the field they actually want is a ticket reference.

"In over 30 years of using source control, I've never once worked on something where it's useful to include the component… 'bug', 'fix' or 'feature' adds no useful value… The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request." — a developer with 30 years of version control

The maintainer of Keep a Changelog showed up to argue the deeper error: Conventional Commits assumes every commit belongs in a release changelog at all.

"this assumes (broadly) that every single commit in a repository is relevant to the eventual version release changelog… it's a huge miss on what communicating about a release typically means" — the maintainer of keepachangelog.com

One commenter noticed something subtler: the convention is now self-reinforcing because the tools write it. "I see more of these conventional commit-style comments recently and it feels like coming from Claude Code," a developer observed — a default system prompt quietly setting a norm across millions of repos.

The real fault line: humans vs. pipelines

The disagreement isn't really about word order. It's about who the commit message is for. If your commits feed a release robot, the type belongs up front where the parser sees it. If they're read by a human bisecting at 2 a.m., the scope is the only part that helps. Evans is right that those are different jobs — and the thread's most honest reading is that Conventional Commits quietly picked the robot, and a lot of people never noticed they'd agreed to write for one.