Clarify commit msg format

[aruediger]

https://github.com/akka/akka/blob/master/CONTRIBUTING.md#creating-commits-and-writing-commit-messages currently just states:

2. First line should be a descriptive sentence what the commit is doing, including
   the ticket number.

When skimming through the commit msgs in the akka and akka-http repos it stands out that they don't adhere to a consistent format.

I suggest we stick to one of the following

• <[+-!=]><module-id> #<ticket> <msg>
• <msg>, #<ticket>
• <msg> (#<ticket>)

and update the contributing guidelines accordingly. (I guess for akka-http it makes sense to just link the akka one.)

[patriknw]

We relaxed the rules around commit messages for some reasons:

1. Make it easier for new, casual, contributors. We always had to tell them how to write the message, which was not a nice first acquaintance.
2. The value of the cryptic <[+-!=]> was low, and could not be trusted. Pretty much everything must be binary compatible. Might be different in http, which should be allowed to move faster, but I think that can be written in clear text in the commit message when and why something is not compatible.
3. The value of the <module-id> was low, and we can use the github tags on the issue (and PR) for that instead.

Remaining was something like, <msg>, #<ticket> and not too strict rules about how it was written or if the ticket number should go first or last.

[ktoso]

Yeah, as Patrik mentions we moved away from the cryptic prefixes as it was confusing newcomers a lot.
I'd attempt to keep the current simpler rules, it's simpler for people to contribute this way, one less thing we need to explain to them when a PR comes in.

Sounds good @akka/akka-http-team ?

[drewhk]

Ticket number and short description are the only two information that are of actual value according to my experience.

[jypma]

👍 on ticket number, since it also triggers github auto-linking. Short description requirements are already somewhat mentioned in CONTRIBUTING, but could be more explicit, e.g. "explain why it was changed, since what is changed is visible in the code already".