Write Imperative Present Tense Sentences about conventionalcommits.org HOT 6 CLOSED

I'm a -1 on this one. Even though it seems like this is probably a good habit to be in, I think it goes against the goal of our specification being as simple and flexible as possible if we start prescribing too many rules about how commit messages should be written. tldr; it adds a step without adding much value IMO.

Perhaps we could compromise and add this to the F.A.Q. section?

should I use the imperative preset tense?

several communities recommend this and it might be a practice worth using.

In our redesign @damianopetrungaro maybe we can make our F.A.Q. a bit better to read and link to?

unrelated, @hbetts perhaps we should all work together and make sure we're not deviating from RFC 2119, I'd like to fix this.

from conventionalcommits.org.

flexible as possible

Making a specification flexible seems like an antithesis of the goal of a specification.

it adds a step without adding much value IMO.

This is definitely how I feel we should be gauging the value of adding an item to the specification.

I'm somewhat on the fence about whether the value outweighs the extra step/recommendation.

I find that the imperative form ensures a commit message description clearly states the change made, which ultimately makes it easier to reason about what my expectations should be for a commit.

However, it's difficult to enforce and easy to not follow.

Perhaps we could compromise and add this to the F.A.Q. section?

I would be fine with that. Though, instead of adding a FAQ question for should I use the imperative preset tense?, maybe generalize it a little, like what writing form should I use?.

unrelated, @hbetts perhaps we should all work together and make sure we're not deviating from RFC 2119, I'd like to fix this.

What did you have in mind, and should we file a separate issue to carry on that discussion?

from conventionalcommits.org.

What did you have in mind, and should we file a separate issue to carry on that discussion?

Yeah let's start with separate issues, I appreciate the set of eyes, I bet we've drifted a bit from the RFC over time; I was fairly new to this when I hammered out the first draft with @jameswomack.

making a specification flexible seems like an antithesis of the goal of a specification.

Fair point, the very act of making a specification is pretty pedantic 😝My major goals drafting the original version of this was to:

1. have a central place to point to for the standard (the documentation was spread out over a few tools).
2. distill the standard into as few steps as possible, such that it's easy to communicate to engineers that it isn't hard to add to your workflow (this is why I dropped some other requirements of angular, e.g., continuing to allow alternative types).

tldr; I'm trying to be resistant towards having too many steps if we can avoid it, which was why I leaned towards the F.A.Q. here.

from conventionalcommits.org.

I am totally fine with this!
I use this already as a best practice in all my commit messages, thanks to @apetro to point it out!

If someone wanna work on it for me it's fine.

@conventional-commits/committee what do you think about it?

from conventionalcommits.org.

@bcoe I agree with you and with @hbetts as well.

I think a good compromise would be using the FAQ and in the new UI I can do the section more relevant adding a link on the top of the page.

from conventionalcommits.org.

I think we covered this in the FAQ \o/

from conventionalcommits.org.