On Mon, Aug 18, 2014 at 3:18 AM, 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 :)
>
> 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
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to