Index: en_US.ISO8859-1/articles/committers-guide/article.xml
===================================================================
--- en_US.ISO8859-1/articles/committers-guide/article.xml
+++ en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -2380,6 +2380,101 @@
+
+ Pre-Commit Review
+
+ Code review is one way to increase the quality of software.
+ The following guidelines apply to commits to the
+ head (-CURRENT) branch of the
+ src repository. Other branches and the
+ ports and docs trees have
+ their own review policies, but these guidelines generally apply
+ to commits requiring review:
+
+
+ All non-trivial changes should be reviewed before they
+ are committed to the repository.
+
+
+
+ Reviews may be conducted by email, in
+ Bugzilla, in
+ Phabricator, or by another
+ mechanism. Where possible, reviews should be public.
+
+
+
+ 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. Specifically,
+ once a patch is sent out for review, it should receive an
+ explicit looks good
before it is committed.
+ So long as it is explicit, this can take whatever form makes
+ sense for the review method.
+
+
+
+ Timeouts are not a substitute for review.
+
+
+
+ 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 are
+ asking for valuable time from other professional
+ developers.
+
+
+
+ Ask for help on mailing lists, IRC, etc. Others
+ may be able to either help you directly, or suggest a
+ 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.
+
+ When making large changes, it is helpful to keep this
+ in mind from the beginning of the effort as breaking large
+ changes into smaller ones is often difficult after the
+ fact.
+
+
+
+ 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 while anyone is welcome to review and give feedback
+ on a patch, only an appropriate subject-matter expert can
+ approve a change. This will usually be a committer who works
+ with the code in question on a regular basis.
+
+ In some cases, no subject-matter expert may be available.
+ In those cases, a review by an experienced developer is
+ sufficient when coupled with appropriate testing.
+
+
Commit Log Messages