<div dir="ltr">Good points from John.<div><br></div><div>The only concern for first time reviewers is that their comments gets overseen by the committer. If the review comment is good, I feel core-reviewer must put some weight on it and thus encourage genuine suggestions.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 9:33 AM, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10/31/2013 10:36 PM, Jeremy Stanley wrote:<br>
</div><div class="im">> As has been said many times already, OpenStack does not lack<br>
> developers... it lacks reviewers.<br>
<br>
</div>In regards to reviews in general and in particular for welcoming new<br>
committers I think we need to be careful about reviewers NAK'ing a<br>
submission for what is essentially bikeshedding [1]. Reviewers should<br>
focus on code correctness and adherence to required guidelines and not<br>
NAK a submission because the submission offends their personal coding<br>
preferences [2].<br>
<br>
If a reviewer thinks the code would be better with changes which do not<br>
affect correctness and are more in the vein of "style" modifications<br>
they should make helpful suggestions but give the review a 0 instead of<br>
actually NAK'ing the submission. NAK'ed reviews based on style issues<br>
force the submitter to adhere to someone else's unsubstantiated opinion<br>
and slows down the entire contribution process while submissions are<br>
reworked multiple times without any significant technical change. It's<br>
also demoralizing for submitters to have their contributions NAK'ed for<br>
reasons that are issues of opinion only, the submitter has to literally<br>
submit [3].<br>
<br>
[1] <a href="http://en.wiktionary.org/wiki/bikeshedding" target="_blank">http://en.wiktionary.org/wiki/bikeshedding</a><br>
<br>
[2] Despite the best attempts of computer science researchers over the<br>
years software development remains more of a craft than a science with<br>
unambiguous rules yielding exactly one solution. Often there are many<br>
valid approaches to solve a particular coding problem, the selection of<br>
one approach often boils down to the personal preferences of the<br>
craftsperson. This does not diminish the value of coding guidelines<br>
gleaned from years of analyzing software issues, what it does mean is<br>
those guidelines still leave plenty of room for different approaches and<br>
no one is the arbiter of the "one and only correct way".<br>
<br>
[3] to give over or yield to the power or authority of another.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>
</div>