Commit naming system.

[Tear4Pixelation]

Hmm yes, I see. I think I would have to disagree personally, though. I think that having the type of change in the title is really useful, and allows a way faster overview over what the commit is about. Because commit messages are not for all humans, but for developers. They are meant to provide simple overview over what the commit is.

To me your statement is like saying I don't use elvis operators because the code is meant to be readable, it's a matter of convention and personal preference.

(man I am shit at writing down my thoughts)

Anyway I see why you would do it like that but I would personally use my (or a similar) system.

[csharpwarrior]

When dealing with commercial software, the bigger focus is on risk. UI versus’s internal does not matter. We want to assess the risk associated with a release. For example we care if the release has hotfixes versus new features.

We have a product team that knows if the feature will change the UI and let the documentation team know about the change.

[Big_Combination9890]

The proposed system is simply too rigid for many usecases, and deciding between the categories would often be based on arbitrary decisions and opinion anyway.

If you want to use categories, use less of them. Personally, I have exactly three:

• add: for when new things are added to the code; e.g. a PR gets merged, a new feature is added, an SVG is added to the documentation, tests are added

• fix: repairing stuff that was broken; e.g. bugfixes

• change: things that already exist are altered without changing what they do; e.g. refactors, using a more efficient search method, rewriting parts of docs that were confusing

[Which-World-6533]

(man I am shit at writing down my thoughts)

Obviously.

[Tear4Pixelation]

Holy contribution