Conventional Commits gets it backwards: scope matters more than type

Conventional Commits prioritizes the type of change (fix, feat, chore) over the scope, but that ordering is exactly wrong. Contributors scanning history, debuggers hunting regressions, and incident responders correlating commits to outages all care first about which area of the code was touched. Type is largely redundant because a well-written description already conveys it, and many real commits legitimately blend bugfix, refactor, and feature work into something a single type label can’t capture.

The format’s headline benefits also don’t hold up. Auto-generated changelogs conflate two audiences with different needs: end users want functional deltas between versions, while developers want the narrative of how the code evolved, and merging them produces a poor version of both. Automatic semver bumps break down around reverts, accidentally-breaking changes discovered later, and retroactive un-breakages — situations where the commit metadata no longer reflects the cumulative diff. Rewriting history to fix this either isn’t allowed by the workflow or rewrites the contributor-facing story.

The author’s underlying argument is that commits are primarily a developer artifact, and a convention that demotes scope to optional while elevating type to a required prefix optimizes for tooling outputs that shouldn’t be derived from commit messages in the first place.