<p dir="ltr">Might be worth calling out the 'common courtesy' ping rate for non-specially-urgent patches which is generally accepted at 1 week.</p>
<div class="gmail_quote">On Aug 22, 2013 6:04 AM, "Manuel Klimek" <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As this seems to be one of the recurring themes (albeit luckily<br>
enough not too often), trying to put up a helpful policy.<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1472" target="_blank">http://llvm-reviews.chandlerc.com/D1472</a><br>
<br>
Files:<br>
  docs/DeveloperPolicy.rst<br>
<br>
Index: docs/DeveloperPolicy.rst<br>
===================================================================<br>
--- docs/DeveloperPolicy.rst<br>
+++ docs/DeveloperPolicy.rst<br>
@@ -128,7 +128,23 @@<br>
    all necessary review-related changes.<br>
<br>
 #. Code review can be an iterative process, which continues until the patch is<br>
-   ready to be committed.<br>
+   ready to be committed. Specifically, once a patch is sent out for review, it<br>
+   needs an explicit "looks good" before it is submitted. Do not assume silent<br>
+   approval, or request active objections to the patch with a deadline.<br>
+<br>
+Sometimes code reviews will take longer than you would hope for, especially for<br>
+larger features. Accepted ways to speed up review times for your patches are:<br>
+<br>
+* review other people's patches; if you help out, everybody will be more<br>
+  willing to do the same for you; goodwill is our currency<br>
+* ping the patch; if necessary, every couple of days; if it is urgent,<br>
+  provide reasons why it is important to you to get this patch landed;<br>
+  remember you're asking for valuable time from other professional developers<br>
+* ask for help on IRC; developers on IRC will be able to either help you<br>
+  directly, or tell you who might be a good reviewer<br>
+* split your patch into multiple smaller patches that build on each other; the<br>
+  smaller your patch, the higher the probability that somebody will take a quick<br>
+  look at it<br>
<br>
 Developers should participate in code reviews as both reviewers and<br>
 reviewees. If someone is kind enough to review your code, you should return the<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div>