ADR proposal for the adoption of conventional commits

[jponge]

No description provided.

[quarkus-bot]

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

• title should preferably start with an uppercase character (if it makes sense!)
• title should not start with chore/docs/feat/fix/refactor but be a proper sentence
• description should not be empty, describe your intent or provide links to the issues this PR is fixing (using Fixes #NNNNN) or changelogs

_{This message is automatically generated by a bot.}

[gsmet]

I'm personally not a big fan of it. Especially since it's going to be a pain to get contributors to follow the format and we will have to either ask them to fix it (either automatically or not) or do it ourselves when they don't.

It's going to be extremely hard to enforce that with the diversity of our contributors. We already struggle just to avoid merge commits in PRs.

Not exactly excited about having more tedious work around that.

[gsmet]

Also, I haven't found any prior discussions about it? Are we supposed to push ADRs without any prior discussions? Asking because they are called decision records so my understanding was that they would be written after some prior discussions and at least a general consent that this is the way to go? But I might have misunderstood.

[gastaldi]

I think that's why the ADR is in a PR: to be discussed and if not agreed we simply close it with a reason of why not adopting it.

I like the idea, a conventional commit message makes the release notes nicer, allowing you to group PRs by kind and also makes you think on the commit message. Plus you get a nicer view when using the Refined Git Chrome extension

[dmlloyd]

I always am of two minds on these things. I would love it if all the commits on all of the projects I deal with were highly tuned for automation.

On the other hand, I absolutely despise doing it, because it means learning another convention, and every project invariably has their own. As someone who writes commits, anything that increases resistance/friction in getting the job done makes me exponentially less likely to bother contributing changes.

Since I spend more of my job creating commits than reading them (whether that's good or bad, I'm not sure), my preference falls somewhere between "can we make this simpler?" and "no thanks".

[maxandersen]

To comment on @gsmet - thé pr is supposed where we discuss and ack or decline the adr.

[maxandersen]

One thing is to enforce it; other is to encourage it.

Could GitHub bot allow it ? Atm it complains if one use the format.

Could we enforce it on PR titles and be lenient on commits ?

I use https://github.com/Ezard/semantic-prs on jbang and have it for titles so I can adjust the title but don't have to be rigid about commit messages.

[dmlloyd]

One thing is to enforce it; other is to encourage it.

Could GitHub bot allow it ? Atm it complains if one use the format.

Could we enforce it on PR titles and be lenient on commits ?

The OpenJDK project has a bot that rewrites the entire PR summary based on the bug ID as well as enforcing structural conventions, which is kinda neat I guess. But, PR descriptions don't typically end up in the commit history, whereas commits do, and presumably this ADR is about commits and particularly their relationship with tooling.