On Mon, Aug 18, 2014 at 3:18 AM, 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 :) > > 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 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. > > We established the design summit as the once-per-cycle opportunity to > have face-to-face time and get alignment across the main contributors to > a project. That used to be completely sufficient, but now it doesn't > work as well... which resulted in alignment and team discussions to be > discussed at mid-cycle meetups instead. Why ? And what could we change > to have those alignment discussions at the design summit again ? > > 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. > For my self, the issue with the design summits have been around the duration and the number of sessions that I would like to attend that are scheduled at the same time. I have rarely seen the issue be too many non-contributors in the room, if they don't have anything to add they usually just listen. The 40 minute format is a bit too restrictive, but if all design summit tracks dropped the 40-min format it would be even harder for me to attend sessions across tracks, one of the main benefits of the design summit IMHO. > > 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. > > Nothing prevents us from changing part of the design summit format (even > the Paris one!), and restrict attendance to some of the sessions. And if > the main issue is the distraction from the conference colocation, we > might have to discuss the future of co-location again. In that "2 events > per year" objective, we could make the conference the optional cycle > thing, and a developer-oriented specific event the mandatory one. > > 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. > > Cheers, > > -- > Thierry Carrez (ttx) > > _______________________________________________ > 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
