RomuloOliveira
not follow the rules
Hi, Thanks for your great guide, but I am just curious that why you do not follow some of the rules in you commit messages?
These should use the imperative form, isn't it?
Hey, @esmaeilpour, that's in fact a good question.
First of all, I don't want to add any friction to contributions. Like I've written in the contributing file they are not rules, they're guidelines and I won't nitpick any commit message from any contributor. If they're really really bad I'd just squash the commits into a new commit with a proper message. In the end, I really not caring so much.
If I was in a development team or maintaining an open source code project, however, I'd definitely enforce them and make sure the messages are the best possible. Regarding specifically the imperative form, I'd probably say "hey, I think it's better to write this way, can you do it differently next time?" but I wouldn't make anyone rewrite a message just because of this.
Another reason is that this project is not code. No one will ever look up in the commit history years from now to find out why some change was done in a particular way neither will have to dive into commit history to understand a broader context or how the project evolved. It's really great when a well-written commit message saves a lot of debugging/troubleshooting/researching time explaining the whys that are not written elsewhere. It won't happen here.
Hey, @esmaeilpour, that's in fact a good question.
First of all, I don't want to add any friction to contributions. Like I've written in the contributing file they are not rules, they're guidelines and I won't nitpick any commit message from any contributor. If they're really really bad I'd just squash the commits into a new commit with a proper message. In the end, I really not caring so much.
If I was in a development team or maintaining an open source code project, however, I'd definitely enforce them and make sure the messages are the best possible. Regarding specifically the imperative form, I'd probably say "hey, I think it's better to write this way, can you do it differently next time?" but I wouldn't make anyone rewrite a message just because of this.
Another reason is that this project is not code. No one will ever look up in the commit history years from now to find out why some change was done in a particular way neither will have to dive into commit history to understand a broader context or how the project evolved. It's really great when a well-written commit message saves a lot of debugging/troubleshooting/researching time explaining the whys that are not written elsewhere. It won't happen here.
You've completely convinced me but I suggest you keep the issue for future questions 😉