Replace 'feat:' with 'new:' #138

New Issue

GiteaMirror · 2026-02-17T11:49:06-06:00

GiteaMirror commented

2026-02-17 11:49:06 -06:00

Originally created by @asashnov on GitHub (Jan 28, 2022).

For me, it takes time to understand what 'feat:' stands for.

'new:' (this commit is adding a new feature) for me is more understandable.

Originally created by @asashnov on GitHub (Jan 28, 2022). For me, it takes time to understand what 'feat:' stands for. 'new:' (this commit is adding a new feature) for me is more understandable.

GiteaMirror commented

2026-02-17 11:49:08 -06:00

@majew7 commented on GitHub (Feb 1, 2022):

This is interesting to consider introducing a type named new:.

I do agree that feat: is a a less readable abbreviation of feature:. Though I do appreciate it's 4 characters like many of the others types.

Q) If a type new: were added, how would you, and other developers, quickly distinguish between a

Feature addition?
Feature removal?
A new documentation paragraph?
A new unit test?

@majew7 commented on GitHub (Feb 1, 2022): This is interesting to consider introducing a type named `new:`. I do agree that `feat:` is a a less readable abbreviation of `feature:`. Though I do appreciate it's 4 characters like many of the others types. **Q)** If a type `new:` were added, how would you, and other developers, quickly distinguish between a * Feature addition? * Feature removal? * A new documentation paragraph? * A new unit test?

GiteaMirror commented

2026-02-17 11:49:10 -06:00

@asashnov commented on GitHub (Feb 21, 2022):

new: - a new feature
drop: - my proposal for feature removal
docs: - any (add/remove) documentation change
test: - any (add/remove) unit test change

Documentation and tests don't need to distinguish add/remove because they follow features usually.

@asashnov commented on GitHub (Feb 21, 2022): new: - a new feature drop: - my proposal for feature removal docs: - any (add/remove) documentation change test: - any (add/remove) unit test change Documentation and tests don't need to distinguish add/remove because they follow features usually.

GiteaMirror commented

2026-02-17 11:49:11 -06:00

@bcoe commented on GitHub (Feb 21, 2022):

Conventional Commits purposely leaves the specification open to folks adding new types:

types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

Because Conventional Commits is based on the Angular conventions originally, which use feat: to indicate new features added, and because there's already a lot of tooling int he ecosystem, I'm not supportive of changing feat to new -- I think it would create more confusion ultimately, by virtue of this being a major breaking change to the spec.

I agree, hindsight 20/20, feature would probably be a better choice than feat for an international audience. Rather than switching feat to new, as the recommendation, I'd rather explicitly state that feature should be treated as an alias of feat -- this feels like it would be a less disruptive change, and would perhaps translate better?

thoughts, comments?

@bcoe commented on GitHub (Feb 21, 2022): Conventional Commits purposely leaves the specification open to folks adding new types: > types other than fix: and feat: are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others. Because Conventional Commits is based on the Angular conventions originally, which use `feat:` to indicate new features added, and because there's already a lot of tooling int he ecosystem, I'm not supportive of changing `feat` to `new` -- I think it would create more confusion ultimately, by virtue of this being a major breaking change to the spec. --- I agree, hindsight 20/20, `feature` would probably be a better choice than `feat` for an international audience. Rather than switching `feat` to `new`, as the recommendation, I'd rather explicitly state that `feature` should be treated as an alias of `feat` -- this feels like it would be a less disruptive change, and would perhaps translate better? _thoughts, comments?_

GiteaMirror commented

2026-02-17 11:49:12 -06:00

@majew7 commented on GitHub (Feb 23, 2022):

Thanks for this response.

Yes feature as an alias of feat could be good, especially for an international audience. And it's shorter than the commonly used type refactor--which I say because I value conciseness too.

@majew7 commented on GitHub (Feb 23, 2022): Thanks for this response. Yes `feature` as an alias of `feat` could be good, especially for an international audience. And it's shorter than the commonly used type `refactor`--which I say because I value conciseness too.

GiteaMirror commented

2026-02-17 11:49:13 -06:00

@pdurbin commented on GitHub (Dec 18, 2022):

I agree, hindsight 20/20, feature would probably be a better choice than feat for an international audience. Rather than switching feat to new, as the recommendation, I'd rather explicitly state that feature should be treated as an alias of feat

I'm new to Conventional Commits, and while I like the idea overall, as even as a native English speaker I'm turned off by "feat". I'd be happy to type three more characters to get "feature" and it looks like @bcoe already created a dedicated "feature as an alias to feat" issue here:

Add clarification for description formatting (#200)

I'd also be happy with a different word but nothing is coming immediately to mind and I agree that "new" is a bit ambiguous.

@pdurbin commented on GitHub (Dec 18, 2022): > I agree, hindsight 20/20, `feature` would probably be a better choice than `feat` for an international audience. Rather than switching `feat` to `new`, as the recommendation, I'd rather explicitly state that `feature` should be treated as an alias of `feat` I'm new to Conventional Commits, and while I like the idea overall, as even as a native English speaker I'm turned off by "feat". I'd be happy to type three more characters to get "feature" and it looks like @bcoe already created a dedicated "feature as an alias to feat" issue here: - #200 I'd also be happy with a different word but nothing is coming immediately to mind and I agree that "new" is a bit ambiguous.

GiteaMirror referenced this issue

2026-02-17 11:58:32 -06:00

[PR #138] [MERGED] Add summary button to welcome section #311

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#138