On 18 August 2014 11:18, Thierry Carrez <thie...@openstack.org> wrote: > Doug Hellmann wrote: >> On Aug 13, 2014, at 4:42 PM, Russell Bryant <rbry...@redhat.com> 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" 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 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 > 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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev