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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189210 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Manuel Klimek 2013-08-26 07:29:08 +00:00
parent 318f4e679b
commit 4989188a40

View File

@ -128,7 +128,24 @@ software. We generally follow these policies:
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