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

[Manuel Klimek]

On Thu, Aug 22, 2013 at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote:

> Might be worth calling out the 'common courtesy' ping rate for
> non-specially-urgent patches which is generally accepted at 1 week.
>
I did some rewording based on your and Matt's feedback - PTAL.


> On Aug 22, 2013 6:04 AM, "Manuel Klimek" <klimek at google.com> wrote:
>
>> As this seems to be one of the recurring themes (albeit luckily
>> enough not too often), trying to put up a helpful policy.
>>
>> http://llvm-reviews.chandlerc.com/D1472
>>
>> Files:
>>   docs/DeveloperPolicy.rst
>>
>> Index: docs/DeveloperPolicy.rst
>> ===================================================================
>> --- docs/DeveloperPolicy.rst
>> +++ docs/DeveloperPolicy.rst
>> @@ -128,7 +128,23 @@
>>     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 necessary, every couple of days; if it is urgent,
>> +  provide reasons why it is important to you to get this patch landed;
>> +  remember 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
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130823/ad9397bf/attachment.html>