Include a clearer policy about what's ok/nok to speed up code reviews.

[klimek]

Summary

As this seems to be one of the recurring themes (albeit luckily
enough not too often), trying to put up a helpful policy.

[dblaikie]

Might be worth calling out the 'common courtesy' ping rate for
non-specially-urgent patches which is generally accepted at 1 week.

[matthewbg]

LGTM, just some copy-editing.

docs/DeveloperPolicy.rst

138–139

Leading cap and trailing dot. I'd also split each of the bullets into two sentences:

• Review other people's patches. If you help out, ... our currency.

[klimek]

Some rewording based on feedback.

[klimek]

Thx. Submitted as r189210.

docs/DeveloperPolicy.rst

 #. Code can be reviewed either before it is committed or after.  We expect major
    changes to be reviewed before being committed, but smaller changes (or
    changes where the developer owns the component) can be reviewed after commit.
 
 #. The developer responsible for a code change is also responsible for making
    all necessary review-related changes.
 
 #. Code review can be an iterative process, which continues until the patch is
-   ready to be committed.
+   ready to be committed. Specifically, once a patch is sent out for review, it
+   needs an explicit "looks good" before it is submitted. Do not assume silent
+   approval, or request active objections to the patch with a deadline.
+
+Sometimes code reviews will take longer than you would hope for, especially for
+larger features. Accepted ways to speed up review times for your patches are:
+
+* Review other people's patches. If you help out, everybody will be more
+  willing to do the same for you; goodwill is our currency.
+* Ping the patch. If it is urgent, provide reasons why it is important to you to
+  get this patch landed and ping it every couple of days. If it is
+  not urgent, the common courtesy ping rate is one week. Remember that you're
+  asking for valuable time from other professional developers.
+* Ask for help on IRC. Developers on IRC will be able to either help you
+  directly, or tell you who might be a good reviewer.
+* Split your patch into multiple smaller patches that build on each other. The
+  smaller your patch, the higher the probability that somebody will take a quick
+  look at it.
 
 Developers should participate in code reviews as both reviewers and
 reviewees. If someone is kind enough to review your code, you should return the
 favor for someone else.  Note that anyone is welcome to review and give feedback
 on a patch, but only people with Subversion write access can approve it.
 
 There is a web based code review tool that can optionally be used
 for code reviews. See :doc:`Phabricator`.