Rethink issue labels and convential commit types

[redeboer]

See Commit conventions and ComPWA repository labels.

• There is a mismatch between the headers of the release drafter.
• Commits that introduce interface changes should become easier to identify. Conventional commit types refactor and chore are too ambiguous.
• Conventional commit type ci is collecting many meanings since 'local' CI, GitHub Actions, and deployment have become more synchronised (through tox).
• The DX and Maintenance labels are also ambiguous.

Need at least labels for:

• Interface changes: scripts that use this library may need to be modified.
• Behaviour changes: same interface, but can output can be affected. Example: refactor: block ComplexSqrt from evaluating ampform#270.
• New features or enhancements. It might be an idea to distinguish between additions to the interface (new features) and performance improvements (enhancement).
• Maintenance: refactoring that does not affect behaviour or interface.
• Improvements to the Developer Experience: some new features that make it easier to develop the framework. These include local improvements as well as improvements to CI and CD.
• Documentation: changes that apply purely to the docs folder, to docstrings in the source code, or to any other explanatory files.

[redeboer]

Perhaps worth to consider the conventions listed here:
https://github-activity.readthedocs.io/en/stable/#splitting-prs-by-tags-and-prefixes

[redeboer]

Settled for the following:

Commit type	Repository label	Description
FEAT	✨ Feature	New features added
ENH	⚙️ Enhancement	Improvements and optimizations of existing features
FIX	🐛 Bug	Bug has been fixed
BREAK	⚠️ Interface	Breaking changes to the API
BEHAVIOR	❗ Behavior	Changes that may affect the framework output
DOC	📝 Docs	Improvements or additions to documentation
MAINT	🔨 Maintenance	Maintenance and upkeep improvements
DX	🖱️ DX	Improvements to the Developer Experience

So an example of a commit would be:

BEHAVIOR: add non-negative assumptions to mass symbols

which would get this PR label:

@spflueger, do you think these cover our PR/commit types?

[spflueger]

Angular conventional commit messages have "breaking change" as an additonal marker independent of the commit type https://www.conventionalcommits.org/en/v1.0.0/#summary . That seems more flexible to me. Im not aware it this can be combined nicely with the release drafter.

[redeboer]

We used to follow these conventional commit types and allowed appending ! (which was done somewhat arbitrarily). I would say this now becomes BREAK.

The major change in the suggested scheme (#7 (comment)) is that the types of 'breaking changes' are clearer. BREAK is a change to the API that might break existing scripts and therefore require a bump in the minor version. (More mature libraries do this through slow, progressive deprecations, but we are still in 0.x.x releases). BEHAVIOR is less severe, but still needs to be clearly signaled to the release notes. It's also important because we provide physics libraries, where sometimes a certain formalism tweak is introduced that may affect physics results, but is not an API change. This was missing so far.