Open Stack

On 08/27/2014 11:34 AM, Doug Hellmann wrote:
>
> On Aug 27, 2014, at 8:51 AM, Thierry Carrez <thierry at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>