Open Stack

On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote:
> Doug Hellmann wrote:
> > On Aug 13, 2014, at 4:42 PM, Russell Bryant <rbryant at 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.
>
> 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.

This pretty much all aligns with my thoughts on the matter. The key point
is that the design summit is the right place from a cycle timing POV to
have the critical f2f discussions & debates, and we need to figure out
what we can do to make it a more effective venue than it currently is.

IME I'd probably say the design summit sessions I've been to fall into
two broad camps. 

 - Information dissemination - just talk through proposal(s) to let
   everyone know what's being planned / thought. Some questions and
   debate, but mostly a one-way presentation.

 - Technical debates - the topic is just a high level hook, around
   which, a lively argument & debate was planned & took place. 

I think that the number of the information dissemination sessions could
be cut back on by encouraging people to take advantage of other equally
as effective methods of communication. In many cases it would suffice to
just have a more extensive blueprint / spec created, or a detailed wiki
page or similar doc to outline the problem space. If we had some regular
slot where people could do online presentations ("Technical talks") that
could be a good way to push the information, out of band from the main
summits. If those online talks led to significant questions, then those
questions could then justify design summit sessions for f2f debate.

As an example, much as it is nice that we give every hypervisor driver
in Nova a slot at the design summit, I wonder whether they are the best
use of our time. Alot of the material in those sessions (including the
libvirt one I led) could have been well disseminated without needing
a design summit. Further much of their material is targetted to a fairly
small subset of the nova community

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|