[feat] Adding new commit terms

Question

[feat] Adding new commit terms

CBID2 opened this issue a year ago · comments

I've been using these terms whenever I review pull requests("Proofreading", nitpicking, and typos). If possible, I would like to add them to the commits list.

Amit Yadav · Answer 1 · Wed Jul 05 2023 14:18:58 GMT+0800 (China Standard Time)

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.

mentalisttraceur · Answer 2 · Wed Aug 23 2023 03:39:28 GMT+0800 (China Standard Time)

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.)

mentalisttraceur · Answer 3 · Wed Aug 23 2023 03:45:44 GMT+0800 (China Standard Time)

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.

Christine Belzie · Answer 4 · Wed Aug 23 2023 05:14:16 GMT+0800 (China Standard Time)

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.

mentalisttraceur · Answer 5 · Wed Aug 23 2023 05:44:42 GMT+0800 (China Standard Time)

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).

Christine Belzie · Answer 6 · Wed Aug 23 2023 07:04:48 GMT+0800 (China Standard Time)

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.

Christine Belzie · Answer 7 · Wed Aug 23 2023 12:07:24 GMT+0800 (China Standard Time)

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

mentalisttraceur · Answer 8 · Wed Aug 23 2023 12:37:58 GMT+0800 (China Standard Time)

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. :)

Christine Belzie · Answer 9 · Wed Aug 23 2023 13:47:21 GMT+0800 (China Standard Time)

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. :)

Mateusz Łoskot · Answer 10 · Thu Dec 14 2023 18:20:24 GMT+0800 (China Standard Time)

@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.