Open Stack

On 08/28/2014 03:31 PM, Sean Dague wrote:
> On 08/28/2014 03:06 PM, Jay Pipes wrote:
>> On 08/28/2014 02:21 PM, Sean Dague wrote:
>>> 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 <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.
>>>
>>> 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).
>>
>> I'm not sure that would be a bad thing :)
>>
>> I think one of the reasons the mid-cycles have been successful is that
>> they have adequately limited the scope of discussions and I think by
>> doing our homework by fully vetting and voting on cross-project sessions
>> and being OK with saying "No, not this time.", we will be more
>> productive than if we had 20+ cross-project sessions.
>>
>> Just my two cents, though..
> 
> I'm not sure it would be a bad thing either. I just wanted to be
> explicit about what we are saying the cross projects sessions are for in
> this case: the 5 key cross project activities the TC believes should be
> worked on this next cycle.
> 
> The other question is if we did that what's running in competition to
> cross project day? Is it another free form pod day for people not
> working on those things?
> 
> 	-Sean
> 
>>
>> -jay
>>
>>
>> _______________________________________________
>> 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
> 
I'm curious to know how many people would be expected to be all in the
same room? And what percentage of these folks are participating in the
conversation and how many are audience?

One of the issues that seem to be universal in the identified discontent
area with summit sessions currently (which gets discussed after each of
the mid-cycles) is that 30 people talking in a room with an audience of
200 isn't very efficient. I wonder if this well intentioned direction
might end up with this result which many folks I talked to don't want.

The other issue that comes to mind for me is trying to allow everyone to
be included in the discussion while keeping it focusing and reducing the
side conversations. If folks are impatient to have their point (or off
topic joke) heard, they won't wait for a turn from whoever is chairing,
they will just start talking. This can create tension for the rest of
the folks who *are* patiently trying to wait their turn. I chaired a day
and a half of discussions at the qa/infra mid-cycle (the rest of the
time was code sprinting) and it was a real challenge in a room of 30
people with a full spectrum of contributor experience (at least one
person made their first contribution in Germany plus there were folks
who have been involved since the beginning) to keep everyone focused on
the topic at hand. Even with just 30 people I had folks upset at me for
asking them to eliminate the side conversations, some left to go to a
breakout room to code or talk and I was told at a break to ensure I
included some folks in a corner who wanted to speak but didn't get a
chance. Unfortunately the (s)he who talks loudest and first format
doesn't favour those contributors whose first language is something
other than English.

I'm for the direction, I just don't want to see it fall over due to
numbers. Plus we have to give ttx a fighting change to chair it.

I welcome your thoughts,
Anita.