That's an interesting article and also meaningful for coders. If I have a patch more than 200 or 300 lines, to split this may be a good idea. Some time, an easy patch with a little more lines would prevent more reviewers to think about it. On Thu, Aug 15, 2013 at 10:12 AM, Robert Collins <robertc at robertcollins.net>wrote: > This may interest data-driven types here. > > > https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ > > 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. > > -Rob > > -- > Robert Collins <rbtcollins at hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130815/19f1fa2e/attachment.html>