Let's change how we review documentation

[Matt Mackall]

I've been noticing a pattern with submissions lately where otherwise
fine patches get held up by repeated bikeshedding of help strings. Help
strings are important, but I don't think this process is optimal:

- people writing code patches often aren't English experts
- rewriting docs by committee is inefficient
- it obscures and slows the process of getting code fixes and
improvements into the tree
- people like me lose track of whether a patch is ready for acceptance
- developers get discouraged

So I'd like to try something different for a while. If a patch that's
primarily code comes with some doc/message changes that are reasonable,
but could stand improving, please DON'T follow up in the initial review
thread. Please instead wait until the initial patch is accepted, then
follow up _with your own patch_ that improves the docs.

Also remember that we are always open to doc improvements, even during
code freezes and on the stable branch. Please mark doc fixes that apply
to stable appropriately

-- 
http://selenic.com : development and support for Mercurial and Linux