<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 5:22 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote:<br>
> Doug Hellmann wrote:<br>
> > On Aug 13, 2014, at 4:42 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> >> Let me try to say it another way. You seemed to say that it wasn't much<br>
> >> to ask given the rate at which things happen in OpenStack. I would<br>
> >> argue that given the rate, we should not try to ask more of individuals<br>
> >> (like this proposal) and risk burnout. Instead, we should be doing our<br>
> >> best to be more open an inclusive to give the project the best chance to<br>
> >> grow, as that's the best way to get more done.<br>
> >><br>
> >> I think an increased travel expectation is a raised bar that will hinder<br>
> >> team growth, not help it.<br>
> ><br>
> > +1, well said.<br>
><br>
> Sorry, I was away for a few days. This is a topic I have a few strong<br>
> opinions on :)<br>
><br>
> There is no denial that the meetup format is working well, comparatively<br>
> better than the design summit format. There is also no denial that that<br>
> requiring 4 travels per year for a "core" dev is unreasonable. Where is<br>
> the limit ? Wouldn't we be more productive and aligned if we did one per<br>
> month ? No, the question is how to reach a sufficient level of focus and<br>
> alignment while keeping the number of "mandatory" travel at 2 per year.<br>
><br>
> I don't think our issue comes from not having enough F2F time. Our issue<br>
> is that the design summit no longer reaches its objectives of aligning<br>
> key contributors on a common plan, and we need to fix it.<br>
><br>
> We established the design summit as the once-per-cycle opportunity to<br>
> have face-to-face time and get alignment across the main contributors to<br>
> a project. That used to be completely sufficient, but now it doesn't<br>
> work as well... which resulted in alignment and team discussions to be<br>
> discussed at mid-cycle meetups instead. Why ? And what could we change<br>
> to have those alignment discussions at the design summit again ?<br>
><br>
> Why are design summits less productive that mid-cycle meetups those days<br>
> ? Is it because there are too many non-contributors in the design summit<br>
> rooms ? Is it the 40-min format ? Is it the distractions (having talks<br>
> to give somewhere else, booths to attend, parties and dinners to be at)<br>
> ? Is it that beginning of cycle is not the best moment ? Once we know<br>
> WHY the design summit fails its main objective, maybe we can fix it.<br>
><br>
> My gut feeling is that having a restricted audience and a smaller group<br>
> lets people get to the bottom of an issue and reach consensus. And that<br>
> you need at least half a day or a full day of open discussion to reach<br>
> such alignment. And that it's not particularly great to get such<br>
> alignment in the middle of the cycle, getting it at the start is still<br>
> the right way to align with the release cycle.<br>
><br>
> Nothing prevents us from changing part of the design summit format (even<br>
> the Paris one!), and restrict attendance to some of the sessions. And if<br>
> the main issue is the distraction from the conference colocation, we<br>
> might have to discuss the future of co-location again. In that "2 events<br>
> per year" objective, we could make the conference the optional cycle<br>
> thing, and a developer-oriented specific event the mandatory one.<br>
><br>
> If we manage to have alignment at the "design summit", then it doesn't<br>
> spell the end of the mid-cycle things. But then, ideally the extra<br>
> mid-cycle gatherings should be focused on getting specific stuff done,<br>
> rather than general team alignment. Think workshop/hackathon rather than<br>
> private gathering. The goal of the workshop would be published in<br>
> advance, and people could opt to join that. It would be totally optional.<br>
<br>
</div></div>This pretty much all aligns with my thoughts on the matter. The key point<br>
is that the design summit is the right place from a cycle timing POV to<br>
have the critical f2f discussions & debates, and we need to figure out<br>
what we can do to make it a more effective venue than it currently is.<br>
<br>
IME I'd probably say the design summit sessions I've been to fall into<br>
two broad camps.<br>
<br>
- Information dissemination - just talk through proposal(s) to let<br>
everyone know what's being planned / thought. Some questions and<br>
debate, but mostly a one-way presentation.<br>
<br>
- Technical debates - the topic is just a high level hook, around<br>
which, a lively argument & debate was planned & took place.<br>
<br>
I think that the number of the information dissemination sessions could<br>
be cut back on by encouraging people to take advantage of other equally<br>
as effective methods of communication. In many cases it would suffice to<br>
just have a more extensive blueprint / spec created, or a detailed wiki<br>
page or similar doc to outline the problem space. If we had some regular<br>
slot where people could do online presentations ("Technical talks") that<br>
could be a good way to push the information, out of band from the main<br>
summits. If those online talks led to significant questions, then those<br>
questions could then justify design summit sessions for f2f debate.<br></blockquote><div><br></div><div><br></div><div>++, I have always found the information dissemination sessions to be a bit silly. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As an example, much as it is nice that we give every hypervisor driver<br>
in Nova a slot at the design summit, I wonder whether they are the best<br>
use of our time. Alot of the material in those sessions (including the<br>
libvirt one I led) could have been well disseminated without needing<br>
a design summit. Further much of their material is targetted to a fairly<br>
small subset of the nova community<br>
<div class="im HOEnZb"><br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>