On 08/28/2014 01:58 PM, Jay Pipes wrote: > On 08/27/2014 11:34 AM, Doug Hellmann wrote: >> >> On Aug 27, 2014, at 8:51 AM, Thierry Carrez <thie...@openstack.org> >> wrote: >> >>> Hi everyone, >>> >>> I've been thinking about what changes we can bring to the Design >>> Summit format to make it more productive. I've heard the feedback >>> from the mid-cycle meetups and would like to apply some of those >>> ideas for Paris, within the constraints we have (already booked >>> space and time). Here is something we could do: >>> >>> Day 1. Cross-project sessions / incubated projects / other >>> projects >>> >>> I think that worked well last time. 3 parallel rooms where we can >>> address top cross-project questions, discuss the results of the >>> various experiments we conducted during juno. Don't hesitate to >>> schedule 2 slots for discussions, so that we have time to come to >>> the bottom of those issues. Incubated projects (and maybe "other" >>> projects, if space allows) occupy the remaining space on day 1, and >>> could occupy "pods" on the other days. >> >> If anything, I’d like to have fewer cross-project tracks running >> simultaneously. Depending on which are proposed, maybe we can make >> that happen. On the other hand, cross-project issues is a big theme >> right now so maybe we should consider devoting more than a day to >> dealing with them. > > I agree with Doug here. I'd almost say having a single cross-project > room, with serialized content would be better than 3 separate > cross-project tracks. By nature, the cross-project sessions will attract > developers that work or are interested in a set of projects that looks > like a big Venn diagram. By having 3 separate cross-project tracks, we > would increase the likelihood that developers would once more have to > choose among simultaneous sessions that they have equal interest in. For > Infra and QA folks, this likelihood is even greater... > > I think I'd prefer a single cross-project track on the first day.
So the fallout of that is there will be 6 or 7 cross-project slots for the design summit. Maybe that's the right mix if the TC does a good job picking the top 5 things we want accomplished from a cross project standpoint during the cycle. But it's going to have to be a pretty directed pick. I think last time we had 21 slots, and with a couple of doubling up that gave 19 sessions. (about 30 - 35 proposals for that slot set). >>> Day 2 and Day 3. Scheduled sessions for various programs >>> >>> That's our traditional scheduled space. We'll have a 33% less >>> slots available. So, rather than trying to cover all the scope, the >>> idea would be to focus those sessions on specific issues which >>> really require face-to-face discussion (which can't be solved on >>> the ML or using spec discussion) *or* require a lot of user >>> feedback. That way, appearing in the general schedule is very >>> helpful. This will require us to be a lot stricter on what we >>> accept there and what we don't -- we won't have space for courtesy >>> sessions anymore, and traditional/unnecessary sessions (like my >>> traditional "release schedule" one) should just move to the >>> mailing-list. >> >> The message I’m getting from this change in available space is that >> we need to start thinking about and writing up ideas early, so teams >> can figure out which upcoming specs need more discussion and which >> don’t. > > ++ > > Also, I think as a community we need to get much better about saying > "No" for certain things. No to sessions that don't have much specific > details to them. No to blueprints that don't add much functionality that > cannot be widely used or taken advantage of. No to specs that don't have > a narrow-enough scope, etc. > > I also think we need to be better at saying "Yes" to other things, > though... but that's a different thread ;) > >>> Day 4. Contributors meetups >>> >>> On the last day, we could try to split the space so that we can >>> conduct parallel midcycle-meetup-like contributors gatherings, with >>> no time boundaries and an open agenda. Large projects could get a >>> full day, smaller projects would get half a day (but could continue >>> the discussion in a local bar). Ideally that meetup would end with >>> some alignment on release goals, but the idea is to make the best >>> of that time together to solve the issues you have. Friday would >>> finish with the design summit feedback session, for those who are >>> still around. >> >> This is a good compromise between needing to allow folks to move >> around between tracks (including speaking at the conference) and >> having a large block of unstructured time for deep dives. > > Agreed. > > Best, > -jay > >>> I think this proposal makes the best use of our setup: discuss >>> clear cross-project issues, address key specific topics which need >>> face-to-face time and broader attendance, then try to replicate >>> the success of midcycle meetup-like open unscheduled time to >>> discuss whatever is hot at this point. >>> >>> There are still details to work out (is it possible split the >>> space, should we use the usual design summit CFP website to >>> organize the "scheduled" time...), but I would first like to have >>> your feedback on this format. Also if you have alternative >>> proposals that would make a better use of our 4 days, let me know. >>> >>> Cheers, >>> >>> -- Thierry Carrez (ttx) >>> >>> _______________________________________________ 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 >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev