I think to make the Summit sessions more effective: 1. The presenter to put in more effort beforehand - implement a rough POC, write up a detailed etherpad, etc. where everything is ready say 2-3 weeks before the Summit. Maybe even require a reviewed spec for sessions which introduce new features? 2. The active members of the project (core and otherwise) to put in more effort beforehand - review the POC and/or etherpad, digest the information, maybe even start a preliminary discussion on IRC to sharpen the proposal 3. Rather than the presenter giving a lecture and the project members trying to digest what is being said, with no time to think of implications, design options, etc., there should just be that debate to refine the idea (I think this is what usually happens at the mid-cycle meetup). 4. Community members who "did not do their homework" should be discouraged from actively participating in that session (i.e., asking basic questions or taking the discussion on tangents). Anyone who has questions or off-topic comments can take it up with the presenter or anyone else during the breaks.
Of course this requires a lot discipline on everyone's part, but I think it would not only make the Summit sessions more valuable, but also help developers who present to get their code in quicker and thereby help the project to meet its objectives for that release. Thanks, Avishay On Mon, Aug 18, 2014 at 6:40 PM, John Griffith <john.griff...@solidfire.com> wrote: > > > > On Mon, Aug 18, 2014 at 9:18 AM, Russell Bryant <rbry...@redhat.com> > wrote: > >> On 08/18/2014 06:18 AM, Thierry Carrez 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. >> > >> > 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. >> >> Great response ... I agree with everything you've said here. Let's >> figure out how to improve the design summit to better achieve team >> alignment. >> >> Of the things you mentioned, I think the biggest limit to alignment has >> been the 40 minute format. There are some topics that need more time. >> It may be that we just need to take more advantage of the ability to >> give a single topic multiple time slots to ensure enough time is >> available. As Dan discussed, there are some topics that we could stand >> to turn down and distribute information another way that is just as >> effective. >> >> I would also say that the number of things going on at one time is also >> problematic. Not only are there several design summit sessions going >> once, but there are conference sessions and customer meetings. The >> rapid rate of jumping around and context switching is exhausting. It >> also makes it a bit harder to get critical mass for an extended period >> of time around a topic. In mid-cycle meetups, there is one track and no >> other things competing for time and attention. >> >> I don't have a good suggestion for fixing this issue with so many things >> competing for time and attention. I used to be a big proponent of >> splitting the event out completely, but I don't feel the same way >> anymore. In theory we could call the conference the optional event, but >> in practice it's going to be required for many folks anyway. I can't >> speak for everyone, but I suspect if you're a senior engineer at your >> company, your presence will be required for customer meetings or key >> conference presentations. I think it'd be naive for us to think that we >> could split our the summit without effectively requiring 4/year travel. >> >> -- >> Russell Bryant >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackfirstname.lastname@example.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > So I really like the direction this thread has taken. I should've been > more clear previously that I noticed a remarkable difference in > productivity and focus for the meetup versus design summit (I was too busy > ranting about the semantics between desired, expected and required for > travel; sorry about that). > > Anyway, over the week-end I started thinking about some proposals for > Cinder at the Paris summit to see if we can take some of what we've learned > in our own experience as well as from this thread to make the design summit > more productive. Duncan pointed out some great ideas around having POC > code for proposals, and I think there are a number of other ideas that have > come up that might help as well. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev