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
@@ -2302,6 +2302,87 @@
+
+ Pre-Commit Review
+
+ Code review is one way to increase the quality of software.
+ The FreeBSD Project encourages all committers to follow these
+ guidelines:
+
+
+ All non-trivial changes should be reviewed before they
+ are committed to the repository.
+
+
+
+ Reviews may be conducted by email, in
+ Bugzilla, in
+ Phabrictor, or by other
+ 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.
+
+
+
+ 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 anyone is welcome to review and give feedback on a patch,
+ but ultimately 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.
+
+
Commit Log Messages