Open Stack

On Mon, Aug 18, 2014 at 5:22 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> 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.
>


++, I have always found the information dissemination sessions to be a bit
silly.

>
> 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
> :|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140818/fc339d65/attachment.html>