[{"cid":58118,"parent_cid":null,"body":"Stop Using Conventional Commits\r\n\r\nhttps://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/\r\n\r\nLobsters: https://lobste.rs/s/oqlpna/stop_using_conventional_commits","created_at":"2026-06-05T18:52:01.924Z","tags":["practices","bot"],"orgs":[],"usrs":[],"created_by":"bot_lobsters","thumb":"https://sumnerevans.com/profile_hu_ec6b45997520a46d.webp","c_comments":1,"c_reactions":"","c_flags":0,"links":[],"flaggers":[],"author_ups":52,"author_downs":4,"author_posts_count":3919,"tag_ups":446,"tag_downs":77,"domain_ups":52,"domain_downs":4,"score":"2026-06-03T10:47:15.288Z","repost_ups":0,"mentions":[],"domains":["sumnerevans.com","lobste.rs"],"comments":"1","reaction_count":"0","reaction_counts":{},"user_reactions":[],"child_comments":[{"cid":58119,"body":"> # [Stop Using Conventional Commits](https://sumnerevans.com/posts/software-engineering/stop-using-conventional-commits/)\r\n>\r\n> You’ve almost certainly encountered Conventional Commits before. It may have reared its ugly head in the changelog of an open source project you’ve used. It may have been the enforced commit format for an open source project you contributed to. A lot of people swear by it. I swear at it.\r\n>\r\n> Even though it is used by a large number of popular open source projects, Conventional Commits is an actively bad standard which encourages focus on the wrong things and fails to deliver on its promises.\r\n>\r\n> ## Focus Failure\r\n>\r\n> Conventional Commits promises to add semantic meaning to commit messages to aid developers and end-users in understanding the changes made in a commit. However, Conventional Commits fails to do this in spectacular fashion. To demonstrate this, let’s look at the anatomy of a conventional commit. According to the Conventional Commit website commit messages should be formatted as follows:\r\n>\r\n> <type>[optional scope]: <description> [optional body] [optional footer(s)]\r\n>\r\n> The commit’s subject line has a <type> (something like fix, feat, chore, docs, or refactor1) describing the type of change. Following that, there is an optional scope, and then a description.\r\n>\r\n> This format has a major failing: type is prioritised over scope. This is exactly backwards.\r\n>\r\n> ## Scope > Type\r\n>\r\n> The scope of a change (the subject of the change) is the most important part of a commit. To demonstrate this, let’s consider why each one of the following stakeholders care about the scope of the change more than the type of the change:\r\n>\r\n> - Contributors: when you are a contributor to a project, you often need to read the commit log to identify changes in the codebase relevant to a certain area of the code. There are many reasons for this including:Wanting to catch up on what has happened since the last time you contributed.Trying to understand where the project’s overall inertia is.Looking for commits that might conflict with your in-progress work when pulling or rebasing.As you read the commit log, you’re looking at what areas were touched. You really do not care about the type of change happening, you care about the scope of the change.\r\n>\r\n> Contributors: when you are a contributor to a project, you often need to read the commit log to identify changes in the codebase relevant to a certain area of the code. There are many reasons for this including:\r\n>\r\n> - Wanting to catch up on what has happened since the last time you contributed.\r\n>\r\n> - Trying to understand where the project’s overall inertia is.\r\n>\r\n> - Looking for commits that might conflict with your in-progress work when pulling or rebasing.\r\n>\r\n> As you read the commit log, you’re looking at what areas were touched. You really do not care about the type of change happening, you care about the scope of the change.\r\n>\r\n> - Debuggers: when investigating a bug, you often want to look through the commit log to see what changes might have touched areas related to the component where the bug manifested. Once again, the scope is the most important piece of information. The type of change is entirely useless because bugs can be introduced in any change regardless of type. (I’m sure we’ve all experienced writing a bugfix that caused another bug.)\r\n>\r\n> …","orgs":[],"tags":["practices","bot"],"usrs":[],"c_flags":0,"comments":0,"created_at":"2026-06-05T18:52:02.716083+00:00","created_by":"bot_reader","parent_cid":58118,"child_comments":[],"user_reactions":[],"reaction_counts":{}}]}]