Have more granular scopes for semantic commit messages

[Josh-Cena]

Since now almost 100% of our commits have the scope v2, this field has lost its usefulness.

Should we have more granular scopes (e.g. theme-classic, plugin-docs) instead?

[slorber]

Honestly, I'm not a fan of commit message scopes (as long as the squashed commit message has a nice description), I'm just following the scopes that were already defined :)

@lex111 @yangshun any opinion on what we should do about those scopes?

For now we keep using docs(v2) etc but this does not make too much sense to do that forever.

https://docusaurus.io/community/contributing#semantic-commit-messages

Also, there are many cases where I'm not even sure which type/scope/github-tag to apply to PRs.
For example what should be the type/scope/tag of updating some theme translation?

[yangshun]

I'm ok with keeping/losing the commit message scopes. Sometimes I wonder which to use as well, but it's ok because it's still more helpful than not using at all. As the maintainer you can decide :)

However the PR tags are necessary for the changelog generation and I think they should stay.

[Josh-Cena]

For example what should be the type/scope/tag of updating some theme translation?

FYI the type should be feat IMO. It's not fix because there's no bug (but rather lack of feature); it's not refactor since the content changes on the user-side. But yeah, it doesn't feel quite like a feature of any kind.

[slorber]

I'm ok with keeping/losing the commit message scopes. Sometimes I wonder which to use as well, but it's ok because it's still more helpful than not using at all. As the maintainer you can decide :)

I'd say:

• we can avoid using (v2) now
• it's not really useful to introduce new scopes as we try to merge PRs with a proper description already which is likely to explain the scope better

@Josh-Cena for newly submitted translations I'm using feat but when there's one missing translation string in an existing translation, I think it can be considered as a bug?

What I think:

• We should have more commit types, like: website / internal / polish / misc / a11y / i18n
• We should have a 1-1 mapping between commit types and PR tags?

Quite often, we associate refactor commit type with polish PR tag, as there's not a direct mapping. We also already use polish/misc commit types occasionally, even if they are not un the "official list of types" (see for example #5156)

Having a system where we keep types but have more choices and a 1-1 mapping would remove a bit of cognitive burden of having to choose the appropriate type/tag.

[Josh-Cena]

but when there's one missing translation string in an existing translation, I think it can be considered as a bug?

I think the only case of a translation bug is a mistranslation 🤷‍♂️ (e.g. wrong plurals) But yeah different people have different interpretations

It's better that we keep a very small subset of commit types, since more types means more ambiguity. Polish, style, perf, etc., have so few uses and can be somehow replaced with refactor or fix. A 1-1 mapping of tags and type would certainly be helpful, and we should also more rigorously define each commit type and let the contributor choose more wisely in the first place instead of we fixing everything for them...

[slorber]

let the contributor choose more wisely in the first place instead of we fixing everything for them...

Contributors will keep not using commit types, and I think it's fine if we fix those.
As we squash all PRs I think only we maintainers should need to handle those commit messages: we could even remove those from the contribution doc.