Add "content" category in commit message guidelines

[pensierinmusica]

Hi,

I've been using the Angular commit messages convention fro more than a year now, and I find it great.

On the other hand, I think there's one type of commits that is very relevant, and it's missing from the list: the "content" type.

Every time I'm working on an app or a website and I need to commit changes to its static content (e.g. text in a page, pictures, titles, etc.) I can't find a good fit in the existing commit types included in the list.

In fact, it's neither "feat", nor "style", nor "docs". Apart from this, I've found the list to be pretty exhaustive.

Therefore, I propose to include the "content" type in the list, with the description "A content change that only affects static text or images" (or something similar).

Let me know your thoughts, and if you'd like me to create a PR for it!

Thanks, cheers :)

p.s. relates to stevemao/conventional-changelog-angular#3

[Narretz]

I think the commit message guidelines don't apply very well to "app" projects. Angular is a framework, so there's not going to be a lot of content. Although we usually use "chore" for content changes on angularjs.org. But I think a content category is out of scope for the commit message guidelines.

[gkalpak]

@Narretz is right, althought it might make sense for a website, we don't have any "content" in this repo. The only content we have is docs (so the docs type is better suited).

Maybe you were thinking about angularjs.org (which is separate repo) ? (But even there, there's no "content" in the tranditional sense of the term, imo.)

[pensierinmusica]

What about the website at http://angular.io ?

[pensierinmusica]

Btw, I understand Angular is a framework and as such has no "content". On the other hand, it looks like @stevemao won't change conventional-changelog-angular unless you approve such a category, which in turn means it can't be integreated as default in cz-conventional-changelog.

Imho the problem is that following the angular convention was a great start, but we can't block all projects in the world from having a useful "content" category because Angular is a framework.

Therefore there are really two solutions I can see to the problem:

1. The Angular team allows the "content" category to be integrated in conventional-changelog-angular.
2. cz-conventional-changelog detaches itself from pure Angular standards

@gkalpak, @Narretz, @jimthedev, and @stevemao thoughts?

[gkalpak]

EDIT: This comment was a reply to https://github.com/angular/angular.js/issues/14210#issuecomment-195010695.

I'm not sure about their commit message conventions. It's a different repo as well. Why don't you post an issue there ? Maybe it's a good fit for them.

BTW, here are the main repos:

• angular.js (ng1): https://github.com/angular/angular.js
• angularjs.org (ng1 website): https://github.com/angular/angularjs.org
• angular (ng2): https://github.com/angular/angular
• angular.io (ng(2) website): https://github.com/angular/angular.io

[gkalpak]

EDIT: This comment it a reply to https://github.com/angular/angular.js/issues/14210#issuecomment-195013441.

I don't think either ng1 or ng2 use conventional-changelog-angular, but there have been discussions about switching to it (IIRC).

The Angular Team does not decide what goes into those projects; only their authors do. I agree that what makes sense for Angular is not making sense for all projects in the world and they shouldn't be blocked (but the Angular Team is definitely not blocking anyone).

Nor does it make sense for Angular to incorporate any commit message type that might be useful for any project in the world.

IMO, (if that's not alredy the case) there should be several "presets" available, e.g. one for applications, another one for libraries, a third one for websites and so on. Different commit message types make sense for different types of projects.

[jimthedev]

I can speak for commitizen. On our site, we offer links to the cz-conventional-changelog commitizen adapter which tracks with @stevemao's conventional-changelog's angular conventions. With that said, anyone who would like to have their own commitizen adapter is free to fork this and maintain their own adapter. We have a bunch of custom adapters listed on our site, and people can add their own to our list if they put a PR in against our readme.md.

I think the best bet at this point is to fork or straight copy cz-conventional-changelog, name it something like cz-website-changelog or whatever, publish to npm, list it on our readme.md as a custom adapter and call it a day. I know it is a bit confusing that cz-conventional-changelog doesn't mention angular in the name even though it tracks that convention, but we've make it super easy to plug in your own adapters that have custom fields or perform completely autonomous operation.

I'd be happy to help by hosting your cz-website-changelog with your own custom fields in the commitizen github organization if you think that would be helpful, but there are enough people relying on the current cz-conventional-changelog adapter assumptions that it is not likely to deviate much at this point.

[pensierinmusica]

@jimthedev I just thought that since cz-conventional-changelog is not only used by the Angular team, it makes sense to have the "content" category available as default.

Would you please consider it? So that people don't need custom configurations to have it.

Then, I know it's possible to create a custom adapter, and thanks for being available to include it in the list. If there's no other way, I'll end up doing this. On the other hand, I'd still invite everyone to reconsider having the "content" category available in cz-conventional-changelog by default as the best course of action. Thoughts? Cheers!

[jimthedev]

@pensierinmusica I appreciate you asking so nicely. I have a hard time saying no to ideas so hopefully you know how tough this is. I certainly understand why it seems like this would be a good idea. The thing is, my goal has always been to keep cz-conventional-changelog as close to the angular specs as possible since that is how it started and people rely on that assumption. I should have named it better, but the key assumptions remain in place for the 25k users that we have per month of that adapter.

It would take a breaking change of that adapter to accomplish this change and as such I don't think that adapter will ever diverge. Partially this is to make sure integration with cz-customizable and semantic-release are easy and consistent, partially it is because this is not a default adapter but rather it is a reference implementation. A reference implementation is meant to show people how they could structure their own adapters. You do not need to use cz-conventional-changelog with commitizen, though many people do. Instead, please fork the reference implementation and make the changes you have for your specific use cases. Chances are that there are others wanting this change, but I am unwilling to make a breaking changes when we don't have an idea of how many people would even use such a feature. If it turns out that your implementation is the preferred then we can change the recommendation in the docs to use that adapter.

TLDR; There is no default commitizen adapter. Adapters are chosen by repo authors. Many use a reference implementation (cz-conventional-changelog), many do not.

[stevemao]

@pensierinmusica if you look at the issues at conventional-changelog, people always have their "own angular convention" which is slightly different than the real "angular convention". I've been working on the project for a long time and this is the first time I've heard "content" so I'd argue this is common use-case to be added in the tools. And most of the rules they make up are different than each other. I think the real "angular convention" works for most repos and it's very easy to modify on top of the angular preset (No need to fork, just require it and modify).

[stevemao]

However, if you ask if there is an easier way to config on top of another config (preset/adapter) the tool authors might think about that. EG: forking a repo might end up many duplicated code and force to sync with upstream etc, I think require would be better (npm is an awesome package manager) (I'm not pointing at commitizen since I know little about it. I'm trying to give an example and talking about similar tools in general). I've always trying to achieve this in my projects.

[pensierinmusica]

@jimthedev thanks for the explanation! I see, I thought that cz-conventional-changelog was the default adapter in case there was no adapter specified. Since it turns out that the user always needs to specify one, now I understand your point much better. I guess we can close this issue, and the related ones, as we've got to a fairly stable point. Thanks everyone for participating and helping out!

[jimthedev]

@pensierinmusica Great! Glad to have the discussion! :+1: