<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 11:42 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>This may interest data-driven types here.<br><br><a href="https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/" target="_blank">https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/</a><br>

<br></div>Note specifically the citation of 200-400 lines as the knee of the review effectiveness curve: that's lower than I thought - I thought 200 was clearly fine - but no.<br><br></div></div></blockquote><div><br>
</div><div>Very interesting article. One other point which I think is pretty relevant is point 4 about getting authors to annotate the code better (and for those who haven't read it, they don't mean comments in the code but separately) because it results in the authors picking up more bugs before they even submit the code.<br>
<br>So I wonder if its worth asking people to write more detailed commit logs which include some reasoning about why some of the more complex changes were done in a certain way and not just what is implemented or fixed. As it is many of the commit messages are often very succinct so I think it would help on the review efficiency side too.<br>
</div><div> <br></div><div>Chris<br><br></div></div></div></div>