<div dir="ltr">That seems mostly reasonable. I'd try to make it more concise, though. The coding standards and developer policy docs should be short.<div><div><br></div><div><div>+Commit message</div><div>+--------------</div><div>+</div><div>+Although we don't enforce the format of commit messages, there are general</div><div>+guidelines that will help review, search in logs, email formatting and so on.</div><div>+Mostly, the rules that apply are similar to other git repositories, such as:</div><div><br></div><div>Maybe just: "Commit messages should be formatted according to the following general guidelines:"</div><div><br></div><div>+* Separate the commit message into title and body.</div><div>+</div><div>+* The title should not have more than 80 columns, although 60/70 would be</div><div>+  better, since that'd fit better into a `git log` or an email subject.</div><div>+</div><div>+* The body, if it exists, should be separated from the title by an empty line.</div><div>+</div><div>+* The body should be aligned to 80 columns and have as many paragraphs as</div><div>+  necessary, but not more than that. Meaning you should be concise, but</div><div>+  explanatory, including a complete reasoning, but leaving examples, code</div><div>+  snippets and gory details to bug comments, web review or the mailing list.</div><div><br></div><div>I don't think the suggestion to be concise is worth putting in the document. More information is usually better.</div><div> </div><div>+* `Attribution of Changes`_ should be in a separate line, after the end of</div><div>+  the body, as simple as "Patch by John Doe.".</div><div>+</div><div>+* Text formatting and spelling should follow the same rules as documentation</div><div>+  and in-code comments, ex. capitalization, full stop, etc.<br></div><div><br></div><div>This point seems borderline, but I guess some people need it.</div><div><br></div><div>+While these rules match most of the cases, we're aware that some cases are not</div><div>+covered, and that's why we don't think reverting patches with "bad" commit</div><div>+messages is a reasonable thing to do. We can, however, remind people of this</div><div>+section of the policy for future reference.</div></div><div><br></div><div>I don't think this paragraph is needed, or it could be shortened to say that these are not hard and fast rules and developers should use their own editorial judgement.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 5:47 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25 September 2014 00:56, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> We could certainly have a little guide for how to write awesome commit logs<br>
> and point people at it. But this is one of (many) aspects of getting ramped<br>
> up on the practices and patterns of the community. Not sure it ever really<br>
> makes sense to try to codify so much as explain it...<br>
<br>
</span>I agree we shouldn't codify or enforce, but educate and remind people<br>
of good practices.<br>
<br>
How about the section attached?<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>