Usefull help message or clickable fill for type?

The whole table seems a bit overwhelming, even if we put it under a collapsed section:

I think that commit type and description (2 columns) might be enough.

Yeah i agree, would be enough.

Would be awesome to make the rows clickable also i think :)

More simple markup:

Once agreed on the format, we can make the elements clickable

Submitted an MR with the above just so we can see where this can be added.

I'll wait for further changes on this issue as the other two open ones have bigger/critical questions that will need answering first before doing any further changes to this UI.

A few of us have been or are away, so we will pick this up next week when we are all back.

There's also the 'breaking change' which can be represented by either a BREAKING CHANGE: note or an exclamation mark like feat!. It looks to me like this is supposed to be used for actual breaking changes, not deprecations, so I don't think we'd use it much in core - maybe for deprecation removals but those are usually the only point of those commits.

I like the more-lightweight format in #5. The spacing between lines could be reduced.

https://www.conventionalcommits.org/en/v1.0.0/ only specifies feat/fix or the ! appended. It looks like the list is up to each project to decide what makes sense for them. Is this set what makes sense for Drupal? How do we decide that? How do we decide when someone asks for another option.

Many / most of our issues are a combination of many of those types. At least test + X. Sometime perf, fix, test, docs all in one. I suppose if we have sufficiently tight scope, some issues could be a single one. But that’s pretty rare. We’d have to assume that fix, feat, perf all imply the corresponding test, docs, etc.

Meanwhile, we use “task” as a catch-all issue category, but we could often be more specific for the commits. So I appreciate the specificity of the list. Yet I wonder if we should use “task” instead of “chore” for Drupal?

#5 looks good for the UI, thanks!

One possible governance mechanism could be to consider the suggested formatting of git history under the auspices of coding standards. We’ve got an active process for that, it includes core people and non core, etc.

Sorry, misread description of “chore”. It’s for non src + test. With build, ci, docs, etc all split out, that doesn’t leave much else a commit could touch. 😂 Maybe “chore” is fine for those cases, and we don’t actually need “task”? 🤔