[GH-ISSUE #643] What is a bug? #5980

New Issue

GiteaMirror · 2026-05-12T17:57:21-05:00

GiteaMirror commented

2026-05-12 17:57:21 -05:00

Originally created by @dabaus on GitHub (Mar 11, 2025).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/643

So we had this discussion in our team that fix should basically only be used when there is a bug ticket. And because of that most people tend to use chore for everything except features and refactor, because
chore implies it's not a bug and low impact.

However, i think that anything that changes a feature in production should be regarded as a fix. And the reasoning behind it is that, even if it was the stakeholder that changed the specification, your application is no longer following the specification for this feature. Thus, you should make a fix for that.

Work-arounds for bugs in other systems, might also be a fix.

My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,

But i don't know. What do you think? What is the intention of fix? Do you think the intention is clear in the current document?

Originally created by @dabaus on GitHub (Mar 11, 2025). Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/643 So we had this discussion in our team that fix should basically only be used when there is a bug ticket. And because of that most people tend to use chore for everything except features and refactor, because chore implies it's not a bug and low impact. However, i think that anything that changes a feature in production should be regarded as a fix. And the reasoning behind it is that, even if it was the stakeholder that changed the specification, your application is no longer following the specification for this feature. Thus, you should make a fix for that. Work-arounds for bugs in other systems, might also be a fix. My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way, But i don't know. What do you think? What is the intention of fix? Do you think the intention is clear in the current document?

GiteaMirror added the discussion label 2026-05-12 17:57:21 -05:00

GiteaMirror commented

2026-05-12 17:57:22 -05:00

@rbalet commented on GitHub (Apr 10, 2025):

He @dabaus .

TLDR;

Bug is ment to be named fix.

-> To know more, read the angular documentation

To your take

My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way,

let me develop a bit..

chore Things that aren't ment to be part of the versioning such as merging branches, bumping a version -> example : chore(release): publish 1.0.0 (Code automated by nx if you're using it)
build or ci: would be use for your configuration changes or any dependencies updates (In case this configuration is in the ci then -> ci)
feat: feat is a new feature, stubs or classes are part of it, but why would you have a class that is not yet in use -> Sounds to be like a red flag -> YAGNI
docs: If you're updating your readme or any documentations
refactor - style : Things that do not effect production in any way and that does not resolve to the others

@rbalet commented on GitHub (Apr 10, 2025): He @dabaus . ## TLDR; `Bug `is ment to be named `fix`. -> To know more, read the [angular documentation](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) ## To your take > My take is that chore should only be used for configuration changes, adding stubs, new classes that are not yet in use , updating readme etc. Things that do not effect production in any way, let me develop a bit.. - `chore` Things that aren't ment to be part of the versioning such as merging branches, bumping a version -> example : `chore(release): publish 1.0.0` (Code automated by nx if you're using it) - `build` or `ci`: would be use for your configuration changes or any dependencies updates (In case this configuration is in the ci then -> `ci`) - `feat`: feat is a new feature, stubs or classes are part of it, but why would you have a class that is not yet in use -> Sounds to be like a red flag -> YAGNI - `docs`: If you're updating your readme or any documentations - `refactor` - `style` : Things that do not effect production in any way and that does not resolve to the others

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#5980