Proposed wording change for the revision log form . . .

I think that's an improvement. I'd move this directly to RTBC, but I haven't actually tried applying it.

See: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476

Looks like a good change to me as well.

Prompting the user to "provide" an explanation is an excellent idea. Much clearer!

I suggest removing "to this content" from #description. Within the context of adding or creating a node, I think it's perfectly clear without it -- and it's always good to keep things as concise as possible!

'#description' => t('Provide an explanation of the changes you are making. This will help other authors understand your motivations.'),

Re-rolled with Todd's changes. Makes plenty of sense to remove 'to this content' here.

+      '#description' => t('Provide an explanation of the changes you are making. This will help other authors understand your motivations.'),

These still seem a bit clumsy. We could do:

+      '#description' => t('To help other authors understand your motivations, provide an explanation for your changes.'),

That's better, but it's less than ideal because people are only going to read the first few words and the operative part is now after the clause.

Is the "motivations" part really necessary? If the idea is for a user to explain their changes, why do we care why they do it? If its not necessary, then why not something as simple as:

+      '#description' => t('Provide an explanation for your changes.'),

Or, if that seems abrupt, then "Please provide an explanation for your changes."

keith.smith: From an efficiency standpoint, it's usually better to tell the user what a thing is before explaining why they should use it.

When someone is quickly scanning a page, they will want to know "what" before "why," as in: "What is this? And why would I want to do that?" Providing "what" before "why" also has the advantage of quickly reminding users of its purpose if they've previously encountered it.

@Todd Nienkerk: OK. I generally agree with #8. I'm not sure what you're suggesting, though. Can you provide a concrete suggestion deriving from either catch's patch in #6 or my suggestions in #7?

I like the patch in #6 so I've committed that. Thanks!

keith.smith: I liked catch's changes in #6. Sorry I wasn't clear on that.