My main objection is this is trying to apply a technical solution to a people+English problem. This feels like just one extra step to have commiters to do, when we as committers can very easily correct this in Github whilst reviewing/before merging.
That said, can you point at any examples of recent commits that you think would have been clearer as a result of using? (Also a significant proportion of commits from form a git gui or an ide, so cz-cli won't help those users.) The "good commit messages" we already link to https://chris.beams.io/posts/git-commit/ has these points 1. Separate subject from body with a blank line 2. Limit the subject line to 50 characters 3. Capitalize the subject line 4. Do not end the subject line with a period 5. Use the imperative mood in the subject line 6. Wrap the body at 72 characters 7. Use the body to explain what and why vs. how 2 we _could_ enforce, but it is not a hard-and-fast rule. 5 and 7 is almost impossible for a computer to enforce. 6 always has exceptions. The most important ones is 7, and that is the hardest to programitcally enforce. -a On Apr 26 2020, at 11:30 am, Jarek Potiuk <jarek.pot...@polidea.com> wrote: > I think it's a very good idea to use it. We already discussed that we > should have some improvements in the way we write commits - and why to > come up with our own conventions if we can adopt one that already > exists and has set of nice tools available. > > As usual, I think automation is a key - as it might make lives of > committers a bit easier. There are already a number of tools that we > could use together with such convention, as both pre-commits and a bot > in Github. > There are quite a few tools that embraced the concept of semantic > pr/semantic commits and I have heard good words about them from other > open-source projects. I've heard especially good words about > commitizen CLI, that could work hand-in-hand with semantic > commits/PRs: > > https://github.com/commitizen/cz-cli > > One of the things it has it also integrates with commit lint where we > could write our own rules and make them more meaningful > https://commitlint.js.org/#/ > > Also, there are ready-to-use changelog generators that we can use (for > example https://github.com/commitizen/cz-conventional-changelog ) > > Those are tools coming from the nodejs world, but I do not see a big > problem with using them (of course trying them out first) - since we > can now connect it via pre-commit, it should be easy to add all that > to our toolbox. > > J. > > > On Sun, Apr 26, 2020 at 10:44 AM Ash Berlin-Taylor <a...@apache.org> wrote: >> >> I agree that many commit messages are often lacking but I'm not a fan >> of that the prefix style that app requires, - plus I think it would >> still be possible to have unhelpful PR titles just with 'fix:' prefixed. >> >> Is rather we as commiters updated the pr subjects when reviewing. The >> rule I try to follow is to (mentally) prefix the message with "When >> this commit is applied it will ..." >> >> -a >> >> On 26 April 2020 09:34:56 BST, Tomasz Urbaszek <turbas...@apache.org> wrote: >> >Hi all! >> > >> >Sometimes it happens that pull requests or commits have not so >> >meaningful messages and it's hard to say what's exactly going on. >> >So I am wondering if we would like to consider using semantic pull >> >request: https://github.com/zeke/semantic-pull-requests >> > >> >Since we are using Github it should be pretty easy to add: >> >https://github.com/apps/semantic-pull-requests >> > >> >Of course, it does not solve the problem of "pr message" but >> >definitely it raises attention about it. On the other hand, it should >> >also help with publishing changelogs. Personally I like this approach >> >and I used to use it before joining Airflow. >> > >> >Happy to see what you think about it. And sorry if it was decided some >> >ago that Airflow won't follow it. >> > >> >Cheers, >> >Tomek > > > > -- > > Jarek Potiuk > Polidea | Principal Software Engineer > > M: +48 660 796 129 >
