[feat] Adding new commit terms about conventionalcommits.org HOT 10 OPEN

Clarifying question: does someone reading the commit need to know that a commit is a [suggested term]?

I think for typo, the answer is yes - when I'm looking over a change history, it can be really useful to distinguish "this change literally only fixed an internal typo" from more significant/big changes of refactor/docs/style/etc type. Usually when I go into commit history, I have a question for which typo fixes are irrelevant (and if mere typo fixes are relevant, I know from the nature of the question I have, before I start looking).

I think for nit, the answer is no - if the change mattered enough to go in, tell future readers why/how. What are you nitting? Does the nit cover some edge case, no matter how tiny/insignificant/unlikely? fix! Does the nit enhance the behavior in a nice-to-have way? feat! Neither of those but changes code? refactor (or style, if the justification is purely that it makes the code more pleasing). Is it a wording nit in a doc/README/comment? docs! And so on.

I think for "proofreading", I can't answer, because I don't know what "proofreading" means here. You're clearly using it in a more specialized way, and maybe you're onto a really useful distinction of change type, but I don't know what it is. (If you can define/explain it, I can probably suggest a better word, especially if I see the usefulness.)

from conventionalcommits.org.

Cheers, thanks for clarifying!

I do make a similar distinction in my commits - for years I've been using "wording {fix,tweak}" for human language / prose adjustments.

Thinking about Conventional Commits and the related convention from Angular, maybe the distinction that matters here is just "is this a purely stylistic change?" without the additional bit of "is this a code change or prose change?" (if the grammar error isn't impactful enough to earn a fix or docs type, style is probably fine).

But if I was version-controlling a specification or book, for example, I would absolutely want to distinguish prose changes from more impactful fixes. A perfect use-case for having a communal CCRFI process/repo ( #537 )! Personally, I propose wording or language as a general catch-all (idk if book editing use-cases would want to get more granular).

Now that I think about it @mentalisttraceur, wording or language does seem more fitting.

from conventionalcommits.org.

Oh, to be clear I don't have any special authority here. I'm just a guy who noticed Conventional Commits recently, here to contribute my ideas and thinking to help this convention and community succeed at its full potential.

I am glad I was able to help you with your proposal, and I'm really hoping that my advocacy for #537 helps create a community norm and place which allows proposals like yours to flourish as extensions, gaining visibility and adoption in as much as they're good/helpful! That's all I can do. :)

from conventionalcommits.org.

Oh, to be clear I don't have any special authority here. I'm just a guy who noticed Conventional Commits recently, here to contribute my ideas and thinking to help this convention and community succeed at its full potential.

I am glad I was able to help you with your proposal, and I'm really hoping that my advocacy for #537 helps create a community norm and place which allows proposals like yours to flourish as extensions, gaining visibility and adoption in as much as they're good/helpful! That's all I can do. :)

Oh thanks for clarifying @mentalisttraceur and what a great proposal you have there. :)

from conventionalcommits.org.

@mentalisttraceur in #529 (comment)

I think for typo, the answer is yes - when I'm looking over a change history, it can be really useful to distinguish "this change literally only fixed an internal typo" from more significant/big changes of refactor/docs/style/etc type.

I buy this rationale and I also miss the typo type of commits.

from conventionalcommits.org.

But eventually these will land you to better open-source contributor.
Proofreading and typos are fine, but nitpicking is not something you need to look for.

from conventionalcommits.org.

P.S. Note that Conventional Commits v1.0.0 only defines fix and feat (feature) change types, but it allows other types - so this seems like the kind of thing best served by defining your own additional convention which extends Conventional Commits by defining one or more change types.

The Conventional Commits community would probably benefit a lot from mimicking something like Scheme's "Request for Implementation" process for stuff like this.

from conventionalcommits.org.

Clarifying question: does someone reading the commit need to know that a commit is a [suggested term]?

I think for typo, the answer is yes - when I'm looking over a change history, it can be really useful to distinguish "this change literally only fixed an internal typo" from more significant/big changes of refactor/docs/style/etc type. Usually when I go into commit history, I have a question for which typo fixes are irrelevant (and if mere typo fixes are relevant, I know from the nature of the question I have, before I start looking).

I think for nit, the answer is no - if the change mattered enough to go in, tell future readers why/how. What are you nitting? Does the nit cover some edge case, no matter how tiny/insignificant/unlikely? fix! Does the nit enhance the behavior in a nice-to-have way? feat! Neither of those but changes code? refactor (or style, if the justification is purely that it makes the code more pleasing). Is it a wording nit in a doc/README/comment? docs! And so on.

I think for "proofreading", I can't answer, because I don't know what "proofreading" means here. You're clearly using it in a more specialized way, and maybe you're onto a really useful distinction of change type, but I don't know what it is. (If you can define/explain it, I can probably suggest a better word, especially if I see the usefulness.)

Thanks for your feedback @mentalisttraceur. To elaborate, proofreading is something I came up with when reviewing pull requests with recurring grammar errors(note: I come from a background in teaching so that also plays an influence in how I formulated this review tactic.

from conventionalcommits.org.

Cheers, thanks for clarifying!

I do make a similar distinction in my commits - for years I've been using "wording {fix,tweak}" for human language / prose adjustments.

Thinking about Conventional Commits and the related convention from Angular, maybe the distinction that matters here is just "is this a purely stylistic change?" without the additional bit of "is this a code change or prose change?" (if the grammar error isn't impactful enough to earn a fix or docs type, style is probably fine).

But if I was version-controlling a specification or book, for example, I would absolutely want to distinguish prose fixes from other kinds of fixes. A perfect use-case for having a communal CCRFI process/repo ( #537 )! Personally, I propose wording or language as a general catch-all (idk if book editing use-cases would want to get more granular).

from conventionalcommits.org.

Now that's settled! :) Do I have your permission to go forth and make my contribution @mentalisttraceur?

from conventionalcommits.org.