<p dir="ltr"><br>
On Aug 20, 2014 10:56 AM, "John Garbutt" <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>> wrote:<br>
><br>
> On 18 August 2014 11:18, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<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>
> Same here, sorry for posting so high up in the tread.<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>
> I think its important we try to get everyone together as often as<br>
> possible, it seems like 2 per year is the best compromise.<br>
><br>
> I prefer "expected" rather than "mandatory", but thats a detail. Some<br>
> times there are more important family things, and thats totally fine.<br>
> But lack of budget seems like a fairly poor excuse for something thats<br>
> "expected".<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>
> > 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>
> What I remember about why we needed the mid-cycles:<br>
><br>
> In Hong Kong:<br>
> * we were missing some key people<br>
> * so the midcycle in the US was very useful to catch up those people<br>
> * but it was great to meet some new contributors<br>
><br>
> In Atlanta, although we have fairly good core attendance, but:<br>
> * done badly on tracking and following on what was discussed<br>
> * we had quite a few information and mentoring sessions, that were not<br>
> a great use of group time<br>
> * had some big debates that needed more time, but we didn't have any slack<br>
> * quite burnt out towards the end (after two previous days of ops and<br>
> cross project sessions)<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>
> It feels a bit exclusive. I think saying we prefer ATLs attending seems OK.<br>
><br>
> Maybe for Paris would could try out some of these things:<br>
><br>
> 1) Get rid of sessions that can be replaced by the spec process:<br>
> * this was a popular idea at the mid-cycle<br>
> * Feature session, we should try write the spec first, to see if we<br>
> really need a session<br>
> * Also use the spec process to help mentor people<br>
> * maybe have more targeted face to face mentor meetings, where a<br>
> summit session is "wasteful"</p>
<p dir="ltr">Yes!</p>
<p dir="ltr">><br>
> 2) Schedule an afternoon of "freestyle big picture debates" later in the week<br>
> * quite often come up with "but we must fix X first" discussions, can<br>
> follow through on those here<br>
> * maybe after lunch on the last day?<br>
> * doesn't mean we don't have other "big picture" sessions explicitly scheduled</p>
<p dir="ltr">Interesting idea, I like it.</p>
<p dir="ltr">><br>
> 3) Schedule a slot to discuss, and propose some release priorities<br>
> * it would be good to generate a release priority "statement" in the<br>
> last session<br>
> * sum up the key "big issues" that have come up and need resolving, etc</p>
<p dir="ltr">++, although I think we need to have a draft of this list when planning the summit to help pick what to talk about.</p>
<p dir="ltr">><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>
> +1<br>
><br>
> Cheers,<br>
> John<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>