Should we adopt conventional commits?

[tdcmeehan]

Today, we follow a few conventions which seem slightly esoteric these days:

1. We follow the git commit guidelines from Chris Beams, as documented in our contributing guide.
2. We add tags to the beginning of commits in an ad-hoc way (see: Discussion: When to add tags to Presto git commits? #21342)

Both of these have problems. The guidelines from Chris Beams help to ensure a clean, readable commit history, but they seem difficult to automate or add validation for. For example, it seems like it would be difficult to ensure that the subject line is in the imperative mood. Moreover, it seems because this is all based off of a blog post instead of a real specification, any attempt to validate these commits would have to be a custom tool. Because there is no validation, sometimes PRs are merged with commits which do not conform to our guidelines.

The tags have issues because we are inconsistently applying them (see #21342).

To recap, we like the current way of structuring commits because it ensures a clean, readable commit history, but we would prefer a little more automation and less room for error.

One idea is to use conventional commits. Conventional commits allow us to continue to continue to preserve a readable commit history, but because the format of the commit actually has a specification, we can add validation on the commit message. A quick browse shows that there's many tools that are ready to use off the shelf that support this specification, so we could quickly add validation.

I think if we were to adopt this specification, it would make the PR review easier for everyone--the PR submitter would quickly understand that their commit does not follow the specification (which is widely known and documented outside of Presto), and the PR reviewer would make less mistakes and leave less repetitive feedback. Thoughts?