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 <robe...@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 <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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.*
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
