On Aug 20, 2014 10:56 AM, "John Garbutt" <[email protected]> wrote: > > On 18 August 2014 11:18, Thierry Carrez <[email protected]> wrote: > > Doug Hellmann wrote: > >> On Aug 13, 2014, at 4:42 PM, Russell Bryant <[email protected]> wrote: > >>> Let me try to say it another way. You seemed to say that it wasn't much > >>> to ask given the rate at which things happen in OpenStack. I would > >>> argue that given the rate, we should not try to ask more of individuals > >>> (like this proposal) and risk burnout. Instead, we should be doing our > >>> best to be more open an inclusive to give the project the best chance to > >>> grow, as that's the best way to get more done. > >>> > >>> I think an increased travel expectation is a raised bar that will hinder > >>> team growth, not help it. > >> > >> +1, well said. > > > > Sorry, I was away for a few days. This is a topic I have a few strong > > opinions on :) > > Same here, sorry for posting so high up in the tread. > > > There is no denial that the meetup format is working well, comparatively > > better than the design summit format. There is also no denial that that > > requiring 4 travels per year for a "core" dev is unreasonable. Where is > > the limit ? Wouldn't we be more productive and aligned if we did one per > > month ? No, the question is how to reach a sufficient level of focus and > > alignment while keeping the number of "mandatory" travel at 2 per year. > > I think its important we try to get everyone together as often as > possible, it seems like 2 per year is the best compromise. > > I prefer "expected" rather than "mandatory", but thats a detail. Some > times there are more important family things, and thats totally fine. > But lack of budget seems like a fairly poor excuse for something thats > "expected". > > > I don't think our issue comes from not having enough F2F time. Our issue > > is that the design summit no longer reaches its objectives of aligning > > key contributors on a common plan, and we need to fix it. > > > > > > Why are design summits less productive that mid-cycle meetups those days > > ? Is it because there are too many non-contributors in the design summit > > rooms ? Is it the 40-min format ? Is it the distractions (having talks > > to give somewhere else, booths to attend, parties and dinners to be at) > > ? Is it that beginning of cycle is not the best moment ? Once we know > > WHY the design summit fails its main objective, maybe we can fix it. > > What I remember about why we needed the mid-cycles: > > In Hong Kong: > * we were missing some key people > * so the midcycle in the US was very useful to catch up those people > * but it was great to meet some new contributors > > In Atlanta, although we have fairly good core attendance, but: > * done badly on tracking and following on what was discussed > * we had quite a few information and mentoring sessions, that were not > a great use of group time > * had some big debates that needed more time, but we didn't have any slack > * quite burnt out towards the end (after two previous days of ops and > cross project sessions) > > > My gut feeling is that having a restricted audience and a smaller group > > lets people get to the bottom of an issue and reach consensus. And that > > you need at least half a day or a full day of open discussion to reach > > such alignment. And that it's not particularly great to get such > > alignment in the middle of the cycle, getting it at the start is still > > the right way to align with the release cycle. > > It feels a bit exclusive. I think saying we prefer ATLs attending seems OK. > > Maybe for Paris would could try out some of these things: > > 1) Get rid of sessions that can be replaced by the spec process: > * this was a popular idea at the mid-cycle > * Feature session, we should try write the spec first, to see if we > really need a session > * Also use the spec process to help mentor people > * maybe have more targeted face to face mentor meetings, where a > summit session is "wasteful"
Yes! > > 2) Schedule an afternoon of "freestyle big picture debates" later in the week > * quite often come up with "but we must fix X first" discussions, can > follow through on those here > * maybe after lunch on the last day? > * doesn't mean we don't have other "big picture" sessions explicitly scheduled Interesting idea, I like it. > > 3) Schedule a slot to discuss, and propose some release priorities > * it would be good to generate a release priority "statement" in the > last session > * sum up the key "big issues" that have come up and need resolving, etc ++, although I think we need to have a draft of this list when planning the summit to help pick what to talk about. > > > If we manage to have alignment at the "design summit", then it doesn't > > spell the end of the mid-cycle things. But then, ideally the extra > > mid-cycle gatherings should be focused on getting specific stuff done, > > rather than general team alignment. Think workshop/hackathon rather than > > private gathering. The goal of the workshop would be published in > > advance, and people could opt to join that. It would be totally optional. > > +1 > > Cheers, > John > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
