FYI, here are the Perl core commit message guidelines, which I quite like (they are consistent with the above, but a bit more general)

Commit message

As you craft each patch you intend to submit to the Perl core, it's important to write a good commit message. This is especially important if your submission will consist of a series of commits.

The first line of the commit message should be a short description without a period. It should be no longer than the subject line of an email, 50 characters being a good rule of thumb.

A lot of Git tools (Gitweb, GitHub, git log --pretty=oneline, ...) will only display the first line (cut off at 50 characters) when presenting commit summaries.

The commit message should include a description of the problem that the patch corrects or new functionality that the patch adds.

As a general rule of thumb, your commit message should help a programmer who knows the Perl core quickly understand what you were trying to do, how you were trying to do it, and why the change matters to Perl.

Why

Your commit message should describe why the change you are making is important. When someone looks at your change in six months or six years, your intent should be clear.

If you're deprecating a feature with the intent of later simplifying another bit of code, say so. If you're fixing a performance problem or adding a new feature to support some other bit of the core, mention that.

What

Your commit message should describe what part of the Perl core you're changing and what you expect your patch to do.

How

While it's not necessary for documentation changes, new tests or trivial patches, it's often worth explaining how your change works. Even if it's clear to you today, it may not be clear to a porter next month or next year.

A commit message isn't intended to take the place of comments in your code. Commit messages should describe the change you made, while code comments should describe the current state of the code.

If you've just implemented a new feature, complete with doc, tests and well-commented code, a brief commit message will often suffice. If, however, you've just changed a single character deep in the parser or lexer, you might need to write a small novel to ensure that future readers understand what you did and why you did it.

On 2014-09-16, the SAT recommended that these guidelines be adopted, along with the development of a training program for new and existing developers to teach them how to follow them.

+1. Who will update the standards docs, and how (I.e, just links to the two offered documents, copy/paste their text, choose one, or write our own text based on these proposals?)

+1

Jeff and Mario have approved; we need to plan the implementation of this decision.

I'm confused: The description of this issue includes a link to a document about what constitutes a good git commit message. Frossie's comment (above) offers alternative text. Which content did the SAT approve?

The SAT did not discuss the specific language, just that such guidelines should exist along the lines of the above suggestions. The above guidelines are not mutually exclusive. I would say that the implementation plan should develop the specific language.

I added the necessary text to https://confluence.lsstcorp.org/display/LDMDG/Git+Commit+Best+Practices.