<p dir="ltr"><br>
Le 18 août 2014 14:36, "Salvatore Orlando" <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> a écrit :<br>
><br>
> As the conversation has drifted away from a discussion pertaining the nova core team, I have some comments inline as well.<br>
><br>
><br>
> On 18 August 2014 12:18, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
>><br>
>> Doug Hellmann wrote:<br>
>> > On Aug 13, 2014, at 4:42 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>> >> Let me try to say it another way. You seemed to say that it wasn't much<br>
>> >> to ask given the rate at which things happen in OpenStack. I would<br>
>> >> argue that given the rate, we should not try to ask more of individuals<br>
>> >> (like this proposal) and risk burnout. Instead, we should be doing our<br>
>> >> best to be more open an inclusive to give the project the best chance to<br>
>> >> grow, as that's the best way to get more done.<br>
>> >><br>
>> >> I think an increased travel expectation is a raised bar that will hinder<br>
>> >> team growth, not help it.<br>
>> ><br>
>> > +1, well said.<br>
>><br>
>> Sorry, I was away for a few days. This is a topic I have a few strong<br>
>> opinions on :)<br>
>><br>
>> There is no denial that the meetup format is working well, comparatively<br>
>> better than the design summit format. There is also no denial that that<br>
>> requiring 4 travels per year for a "core" dev is unreasonable. Where is<br>
>> the limit ? Wouldn't we be more productive and aligned if we did one per<br>
>> month ? No, the question is how to reach a sufficient level of focus and<br>
>> alignment while keeping the number of "mandatory" travel at 2 per year.<br>
><br>
><br>
> I honestly think that it is simply not possible to require a minimum travel from core team members.<br>
> This might sound naive, but I reckon the various core teams could just use a bit of common sense here.<br>
> A core member that goes to every summit and meetup just for doing pub crawling in yet another city is definetely less productive than another team members which tries to collaborate remotely via etherpad/IRC/gerrit/etc. (ok this example was a bit extreme but I hope it clarifies my thoughts).<br>
> <br>
>><br>
>><br>
>> I don't think our issue comes from not having enough F2F time. Our issue<br>
>> is that the design summit no longer reaches its objectives of aligning<br>
>> key contributors on a common plan, and we need to fix it.<br>
><br>
><br>
> I totally agree on this point. I would be suprised if I were the first one that in conversation (off and on the record) has mentioned that it is very hard to achieve any form of consensus on anything at the design summit. And it is pretty much impossible to move from a "declarations of intent" to the definition of an architecture and/or actionable work items for the subsequent release cycle.<br>
> Disclaimer: I spend 90% of my design summit time in the networking room, so my judgment might be skewed.<br>
><br>
>><br>
>> We established the design summit as the once-per-cycle opportunity to<br>
>> have face-to-face time and get alignment across the main contributors to<br>
>> a project. That used to be completely sufficient, but now it doesn't<br>
>> work as well... which resulted in alignment and team discussions to be<br>
>> discussed at mid-cycle meetups instead. Why ? And what could we change<br>
>> to have those alignment discussions at the design summit again ?<br>
><br>
><br>
> I suggested in the past to decouple the summit from the main conference.<br>
> This alone, in my opinion, would allow us to do the design summit at a point where it's best for the upcoming release cycle, and reduce the inevitable increased noise from rooms filled with over 150 people.</p>
<p dir="ltr">Strong -1 here.<br>
Having design sessions happening in the same time than conference is cool for having :<br>
- mixup of operators, developers and users in the same area, enjoying the atmosphere, creating a same view and team spirit within Openstack<br>
- newcomers able to join their first developers sessions (we lower the bar)<br>
- same budget for contributors able to propose good proposals for regular conference</p>
<p dir="ltr">I had the chance to attend both Icehouse and Juno summits. IIRC, Icehouse design summit was restricted to ATCs while Juno one was open to everyone. That thing plus the fact that the audio quality of the Juno sessions was poor (cf. last design session about feedback) makes me think that the problem is rather a problem of having good sessions than more an overall problem.</p>
<p dir="ltr">I'm pro restricting access to only ATCs and impose access to rooms only before the session starts, that would improve dramatically the quality without sending a bad signal to the community that now design discussions are a matter of only engineers.</p>
<p dir="ltr">-Sylvain</p>
<p dir="ltr">> <br>
>><br>
>><br>
>> Why are design summits less productive that mid-cycle meetups those days<br>
>> ? Is it because there are too many non-contributors in the design summit<br>
>> rooms ? Is it the 40-min format ? Is it the distractions (having talks<br>
>> to give somewhere else, booths to attend, parties and dinners to be at)<br>
>> ? Is it that beginning of cycle is not the best moment ? Once we know<br>
>> WHY the design summit fails its main objective, maybe we can fix it.<br>
><br>
><br>
> I think all of them apply and possibly other reasons, but probably we are a going a bit off-topic. <br>
>><br>
>><br>
>> My gut feeling is that having a restricted audience and a smaller group<br>
>> lets people get to the bottom of an issue and reach consensus. And that<br>
>> you need at least half a day or a full day of open discussion to reach<br>
>> such alignment. And that it's not particularly great to get such<br>
>> alignment in the middle of the cycle, getting it at the start is still<br>
>> the right way to align with the release cycle.<br>
>><br>
>> Nothing prevents us from changing part of the design summit format (even<br>
>> the Paris one!), and restrict attendance to some of the sessions. And if<br>
>> the main issue is the distraction from the conference colocation, we<br>
>> might have to discuss the future of co-location again. In that "2 events<br>
>> per year" objective, we could make the conference the optional cycle<br>
>> thing, and a developer-oriented specific event the mandatory one.<br>
><br>
><br>
> While I agree that restricted attendance would increase productivity, it might also be perceived as a "barrier" for new contributors and a reduction of the overall "democracy" of the project. Maybe this could be achieved "naturally" by decoupling conference and summit.<br>
> <br>
>><br>
>><br>
>> If we manage to have alignment at the "design summit", then it doesn't<br>
>> spell the end of the mid-cycle things. But then, ideally the extra<br>
>> mid-cycle gatherings should be focused on getting specific stuff done,<br>
>> rather than general team alignment. Think workshop/hackathon rather than<br>
>> private gathering. The goal of the workshop would be published in<br>
>> advance, and people could opt to join that. It would be totally optional.<br>
><br>
><br>
> I too agree mid-cycle meetups should be focused - for instance as we did for load balancing in June and Neutron QA in January. If they end up being "mini summits", as ttx says, this probably just tell us we need to rethink the main design summit.<br>
> <br>
>><br>
>><br>
>> Cheers,<br>
>><br>
>> --<br>
>> Thierry Carrez (ttx)<br>
>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
></p>