<div dir="ltr">For me nitpicking during review is really not a good experience, however i do think we should tolerate at least one round of nitpicking.<div><br></div><div>On another aspect, the nitpicking review culture also in some way encourage, and provide legitimacy in some way, to the padding activities. People are feeling ok about "fixing dictionary" as we joked. </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 1, 2018 at 4:55 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2018-05-31 16:49:13 -0400 (-0400), John Dennis wrote:<br>
> On 05/30/2018 08:23 PM, Jeremy Stanley wrote:<br>
> > I think this is orthogonal to the thread. The idea is that we should<br>
> > avoid nettling contributors over minor imperfections in their<br>
> > submissions (grammatical, spelling or typographical errors in code<br>
> > comments and documentation, mild inefficiencies in implementations,<br>
> > et cetera). Clearly we shouldn't merge broken features, changes<br>
> > which fail tests/linters, and so on. For me the rule of thumb is,<br>
> > "will the software be better or worse if this is merged?" It's not<br>
> > about perfection or imperfection, it's about incremental<br>
> > improvement. If a proposed change is an improvement, that's enough.<br>
> > If it's not perfect... well, that's just opportunity for more<br>
> > improvement later.<br>
> <br>
> I appreciate the sentiment concerning accepting any improvement yet on the<br>
> other hand waiting for improvements to the patch to occur later is folly, it<br>
> won't happen.<br>
> <br>
> Those of us familiar with working with large bodies of code from multiple<br>
> authors spanning an extended time period will tell you it's very confusing<br>
> when it's obvious most of the code follows certain conventions but there are<br>
> odd exceptions (often without comments). This inevitably leads to investing<br>
> a lot of time trying to understand why the exception exists because "clearly<br>
> it's there for a reason and I'm just missing the rationale" At that point<br>
> the reason for the inconsistency is lost.<br>
> <br>
> At the end of the day it is more important to keep the code base clean and<br>
> consistent for those that follow than it is to coddle in the near term.<br>
<br>
</div></div>Sure, I suppose it comes down to your definition of "improvement." I<br>
don't consider a change proposing incomplete or unmaintainable code<br>
to be an improvement. On the other hand I think it's fine to approve<br>
changes which are "good enough" even if there's room for<br>
improvement, so long as they're "good enough" that you're fine with<br>
them possibly never being improved on due to shifts in priorities.<br>
I'm certainly not suggesting that it's a good idea to merge<br>
technical debt with the expectation that someone will find time to<br>
solve it later (any more than it's okay to merge obvious bugs in<br>
hopes someone will come along and fix them for you).<br>
<span class="HOEnZb"><font color="#888888">-- <br>
Jeremy Stanley<br>
</font></span><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Product Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div></div></div>
</div>