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.
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 OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing
list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
