Ever considered making 'feature' synonymous with 'feat'? #52

New Issue

GiteaMirror · 2026-02-17T11:39:18-06:00

GiteaMirror commented

2026-02-17 11:39:18 -06:00

Originally created by @johnslemmer on GitHub (Nov 5, 2018).

There is a lot wisdom in coding that variable names etc shoudn't be shortened or abbreviated. It makes code more readable. And we all know code is read a lot more than it is written.

So, with that in mind have you thought about making it acceptable to write feature instead of just feat? (I would love to see feat dissapear but too much time has passed and there is too much history and tooling dependent on this that a breaking change like this wouldn't be possible). Right now the spec is very strict when it comes to this, and I was hoping that feature could be added to the spec.

Every other "commit type" is a fully written out word (except perf I guess, but the non-spec types don't really matter as much because it just depends on the tooling a project used). Anyway, it seems reasonable to allow people to follow that pattern.

Lastly, on a personal note, I just started using standard-version to help maintain my personal projects, and found that I kept writing feature: some new feature was added in commit statements because I'm pretty anal about writing out words for readability. Obviously this isn't a big deal, and I just edited all of my past incorrect commit statements. But it seems to me that feature is a reasonable word to add to the spec.

Thanks for coming up with this spec, and allowing it to drive some wonderful tooling!!

Originally created by @johnslemmer on GitHub (Nov 5, 2018). There is a lot wisdom in coding that variable names etc shoudn't be shortened or abbreviated. It makes code more readable. And we all know code is read a lot more than it is written. So, with that in mind have you thought about making it acceptable to write `feature` instead of just `feat`? (I would love to see `feat` dissapear but too much time has passed and there is too much history and tooling dependent on this that a breaking change like this wouldn't be possible). Right now the spec is very strict when it comes to this, and I was hoping that `feature` could be added to the spec. Every other "commit type" is a fully written out word (except `perf` I guess, but the non-spec types don't really matter as much because it just depends on the tooling a project used). Anyway, it seems reasonable to allow people to follow that pattern. Lastly, on a personal note, I just started using [standard-version](https://github.com/conventional-changelog/standard-version) to help maintain my personal projects, and found that I kept writing `feature: some new feature was added` in commit statements because I'm pretty anal about writing out words for readability. Obviously this isn't a big deal, and I just edited all of my past incorrect commit statements. But it seems to me that `feature` is a reasonable word to add to the spec. Thanks for coming up with this spec, and allowing it to drive some wonderful tooling!!

GiteaMirror closed this issue

2026-02-17 11:39:19 -06:00

GiteaMirror commented

2026-02-17 11:39:20 -06:00

@stevemao commented on GitHub (Nov 14, 2018):

Just in general I try to avoid too many options because of tragedy of the commons. And also this spec is supposed to be strict.

@stevemao commented on GitHub (Nov 14, 2018): Just in general I try to avoid too many options because of [tragedy of the commons](https://en.wikipedia.org/wiki/Tragedy_of_the_commons). And also this spec is supposed to be strict.

GiteaMirror commented

2026-02-17 11:39:21 -06:00

@johnslemmer commented on GitHub (Nov 15, 2018):

Makes sense. Thanks for thinking about it.

@johnslemmer commented on GitHub (Nov 15, 2018): Makes sense. Thanks for thinking about it.

GiteaMirror commented

2026-02-17 11:39:23 -06:00

@rbwhitaker commented on GitHub (Jul 23, 2019):

Well I'm late to the party, but I have to agree. I think "feature" is far better. So many code style guides require that you spell out the words rather than arbitrarily shortening them. I'd rather "feature" be the choice here, not "feat." (Though I'd also get behind both options.)

I love what you've got going on here. I think this is a thing our company has been needing. But the "feet" [sic] thing bugs me enough to make me seriously consider just coming up with our own convention. I'm going to bring up Conventional Commits to the other leads here and see what they think. It might not bother them as much and we might just roll with it as it is.

But I do want to make you(@stevemao) aware of the fact that this isn't just one person with a personal preference. It's a larger group of at least two. ("There are dozens of us!")

I get the tragedy of the commons thing; I think it is a good rule of thumb to keep it simple. But this might be a reasonable exception to that.

@rbwhitaker commented on GitHub (Jul 23, 2019): Well I'm late to the party, but I have to agree. I think "feature" is far better. So many code style guides require that you spell out the words rather than arbitrarily shortening them. I'd rather "feature" be the choice here, not "feat." (Though I'd also get behind both options.) I love what you've got going on here. I think this is a thing our company has been needing. But the "feet" [sic] thing bugs me enough to make me seriously consider just coming up with our own convention. I'm going to bring up Conventional Commits to the other leads here and see what they think. It might not bother them as much and we might just roll with it as it is. But I do want to make you(@stevemao) aware of the fact that this isn't just one person with a personal preference. It's a larger group of at least two. ("There are dozens of us!") I get the tragedy of the commons thing; I think it is a good rule of thumb to keep it simple. But this might be a reasonable exception to that.

GiteaMirror referenced this issue

2026-02-17 11:56:30 -06:00

[PR #52] [MERGED] fix: polish typos fix and index pointing to beta.2 #263

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#52