Open Stack

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).

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


-- 
Sean Dague
http://dague.net