Sure, thanks! And suggest add the time and channel information at the kuryr wiki page.
On Wed, Nov 4, 2015 at 9:45 PM, Antoni Segura Puimedon < toni+openstac...@midokura.com> wrote: > > > On Wed, Nov 4, 2015 at 2:38 PM, Baohua Yang <yangbao...@gmail.com> wrote: > >> +1, Antoni! >> btw, is our weekly meeting still on meeting-4 channel? >> Not found it there yesterday. >> > > Yes, it is still on openstack-meeting-4, but this week we skipped it, > since some of us were > traveling and we already held the meeting on Friday. Next Monday it will > be held as usual > and the following week we start alternating (we have yet to get a room for > that one). > >> >> On Wed, Nov 4, 2015 at 9:27 PM, Antoni Segura Puimedon < >> toni+openstac...@midokura.com> wrote: >> >>> Hi Kuryrs, >>> >>> 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: >>> >>> 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). >>> 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. >>> 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: >>> * conciseness, >>> * simplicity, >>> * loose coupling, >>> * logging and error reporting, >>> * test coverage, >>> * extensibility (when an immediate pending and blueprinted feature >>> can better be built on top of it). >>> * documentation, >>> * performance. >>> >>> 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. >>> >>> Regards, >>> >>> Toni >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best wishes! >> Baohua >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best wishes! Baohua
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev