<div dir="ltr">+1, Antoni!<div>btw, is our weekly meeting still on meeting-4 channel? </div><div>Not found it there yesterday.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon <span dir="ltr"><<a href="mailto:toni+openstackml@midokura.com" target="_blank">toni+openstackml@midokura.com</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><div><div><div><div><div><div><div><div>Hi Kuryrs,<br><br></div>Last
 Friday, as part of the contributors meetup, we discussed also code 
contribution etiquette. Like other OpenStack project (Magnum comes to 
mind), the etiquette for what to do when there is disagreement in the 
way to code a blueprint of fix a bug is as follows:<br><br></div>1.- Try
 to reach out so that the original implementation gets closer to a 
compromise by having the discussion in gerrit (and Mailing list if it 
requires a wider range of arguments).<br></div>2.- If a compromise can't
 be reached, feel free to make a separate implementation arguing well 
its difference, virtues and comparative disadvantages. We trust the 
whole community of reviewers to be able to judge which is the best 
implementation and I expect that often the reviewers will steer both 
submissions closer than they originally were.<br></div>3.- If both 
competing implementations get the necessary support, the core reviewers 
will take a specific decision on which to take based on technical merit.
 Important factor are:<br>    * conciseness,<br>    * simplicity,<br></div>    * loose coupling,<br></div>    * logging and error reporting,<br></div><div>    * test coverage,<br></div>    * extensibility (when an immediate pending and blueprinted feature can better be built on top of it).<br></div><div>    * documentation,<br></div><div>    * performance.<br></div><div><br></div>It
 is important to remember that technical disagreement is a healthy thing
 and should be tackled with civility. If we follow the rules above, it 
will lead to a healthier project and a more friendly community in which 
everybody can propose their vision with equal standing. Of course, 
sometimes there may be a feeling of duplicity, but even in the case 
where one's solution it is not selected (and I can assure you I've been 
there and know how it can feel awkward) it usually still enriches the 
discussion and constitutes a contribution that improves the project.<br><br></div>Regards,<br><br></div>Toni</div>
<br>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#999999">Best wishes!<br>Baohua<br></font></div>
</div>