Document `care:` as an alias to `chore:`
fanf opened this issue · comments
Even if not part of the core specification and not always self-explaining (see #493 and especially FlowingCode/DevelopmentConventions#11), chore: is widely used as a general purpose tag for "maintenance things related the code base and its ecossytem, not covered by other tags".
Standard examples are updating library dependencies, cleaning up indents or comments, change related to developer team tooling, etc.
I also saw it used in a several place as a general purpose tag for things related to arch, refactoring, etc when the number of tags used in the project is small (ie restricted to fix, feat, (build - not always there,) and chore)
I would like to advocate for the use of care in place of, are at least as an alternative to, chore. I do understand that the prior-use of chore is huge and other may/won't agree with the reasons exposed at the end, so it could just be having it listed in the point '4', rephrasing it to (for ex:):
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 [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 like `care:` as an alternative to `chore:`.
I also do understand that it's up to everyone to use whatever they want to use in their code base, but the fact that a tag type is not quoted in site makes it ignored by most tooling and out of the horizon of possible choice for most people.
Reason:
chore bears with it the fact that it is something that needs to be done but is a pain, and that you won't like doing it. It may even be more negative in some foreign language, like in French where its translation "corvée" was a totally injust and painful taxe on the poorers for their lord, bordering with slavery (imposed free work controlled by a master blurring the lines of weither the serf were the possession of the master or noy). Even withouy going that far, in French corvée remains an extremelly negative term felt like a punishment done by the poorer/less valued in the standard western/patriarchal value system (I think/believe in English, and esp US English, it lost most of that old meaning and is less negative, more like a routine task/ daily job to keep things tiddy).
But in the case of software, we clearly know why we do these things, and why they are important, and it's cool to do them, and nice, and we can be prood of them: it's because we want a sustainable code base, and because we care about the quality of the code and general developer experience.
We care that other developers will find a well working IDE configuration, we care that the conventions, even the one not automatically checked, are respected and corrected when not, we care that the license headers are present, we care that the depencies are up to date to minise rot and security exposition, we care that the comments are accurate even if we didn't change anything in the code logic and were just reading the sources, in the "let it in better shape than when you came" way of practicing.
For all that, the kind of changes generally associated to the chore: tag should be linked to a care: tag.
(amazingly, we don't have a word for "care" in French, but only periphrasis...)
This reminds me of the master/slave controversy, which I can empathize with. However, the word "chore" doesn't have the same etymological burden as the French word "corvée" (which, as a French-speaking Belgian, I only consider as neutral at best, and dreadful at worst — I had no idea about its original meaning). Furthermore, while software development is awesome, "chore" commits tend to be just that. "We care" indeed, just like we care for our guests to find themselves in a tidy environment when they visit, which is why we do our chores
(amazingly, we don't have a word for "care" in French, but only periphrasis...)
Soin!
The linked commit doesn't include chore:, so the text is out of date. angular/angular@dff6ee3 removed chore:. It really is overused. Just don't mention it.
angular/angular@dff6ee3 removed
chore:.
I did notice, a while back actually, and could understand why. Do you reckon it should indeed be abolished altogether? Or is it just massively overused?
style: was also removed: angular/angular@c1bc070. For this one, the link is out of date, as the linked commit includes it.
Do you reckon it should indeed be abolished altogether? Or is it just massively overused?
Do you have any idea?
style:was also removed: angular/angular@c1bc070. For this one, the link is out of date, as the linked commit includes it.
It apparently wasn't included in the commit parser configuration, but why wasn't it added to the parser rather than removed from the documentation? Is it because of CI style checking, and confidence in the fact that their style wouldn't change?
To answer both. I think there are more fitting types. In particular, a style: is likely to overlap with refactor:. If there isn't, you can invent your own, because
chore: can set a bad example. Rely on it, and a repository will likely not see more fitting types invented for subsets of chore:. Remember Why Use Conventional Commits.
In particular, a
style:is likely to overlap withrefactor:.
Isn't style specific to formatting-related changes, which don't affect the code's meaning?
chore:can set a bad example. Rely on it, and a repository will likely not see more fitting types invented for subsets ofchore:.
I neglected the importance of inventing new types. Is it considered that sub-types of chore can't be made universal enough to be standardized, or has no one gotten around to doing so yet?
Remember Why Use Conventional Commits.
What a you referring to?