{{{
#!html
BarnOwl has a pre-commit code review policy. Essentially all code that
goes to the master branch of the primary repository should be reviewed
and ACKed by at least one other developer.

<ul>
<li>
   <p>There is no official standard for who is allowed to ACK what. It
   suffices that both the author and the reviewer feel confident in their
   ability to evaluate the change.</p>

   <p>Larger changes, however, such as significant refactorings or design of
   non-trivial features, should be informed by
   broader discussion whenever possible.</p>
</li>
<li><p>
   An important part of code review is explicit communication from the
   reviewer. Review comments should include either a clear ACK, or one
   or more clear action items for the developer (generally of the form
   "make this change" or "answer this question").
</p></li>
<li><p>
 The use of a "Reviewed-by:" line by the reviewer is suggested but
   not mandatory as an indicator that the reviewer is happy with the
   patch in its present form. Developers are encouraged but not
   required to include any applicable "Reviewed-by:" lines in the
   commit message of the patch when it is merged.
</p></li>
<li><p>
 While code review of small patches may happen over Zephyr, or
   larger patches if a convenient reviewer is present and paying
   attention, decisions or review of non-trivial branches should, in
   general, happen at least largely over email (to
   barnowl-dev@mit.edu).  Pull requests made on
   github (http://github.com/barnowl/barnowl/pulls) automatically
   send email to barnowl-dev@mit.edu, as do comments on the pull
   request itself.  (Comments on individual commits, or on specific
   lines of a diff, do not result in email notification, and,
   furthermore, are lost if the developer updates the pull request.
   Therefore, please make all comments on the pull request itself.)
</p></li>
<li><p>
 Review requests made by any medium other than github pull requests should include at least one of:</p>
 <ul>
   <li>The location of a git repository containing the changes.</li>
   <li>The patch(es) themselves inline in email (using e.g. <code>git format-patch</code> and <code>git send-email</code>).</li>
   </ul>
   <p>In general, the latter is suggested only for short patches or patch series. It is preferred but not required that such requests also include the location of a git branch.
</p></li>
<li><p>
 If a review request to the mailing list is not responded to in any
   way within seven days from time of sending, the developer may, at
   their option, merge it to master without review.  As pull requests
   on github now send email to the mailing list, this timeout policy
   also applies to github pull requests made after May 20, 2013.  There is no such
   timeout for review requests communicated in any other way.
</p></li>
</ul>
}}}