[openstack-dev] [all] A proposal to separate the design summit

Anita Kuno anteaya at anteaya.info
Mon Feb 29 19:13:06 UTC 2016

On 02/22/2016 10:49 AM, Daniel P. Berrange wrote:
> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>> Hi everyone,
>> TL;DR: Let's split the events, starting after Barcelona.
> Yes, please. Your proposal addresses the big issue I have with current
> summits which is the really poor timing wrt start of each dev cycle.
>> The idea would be to split the events. The first event would be for upstream
>> technical contributors to OpenStack. It would be held in a simpler,
>> scaled-back setting that would let all OpenStack project teams meet in
>> separate rooms, but in a co-located event that would make it easy to have
>> ad-hoc cross-project discussions. It would happen closer to the centers of
>> mass of contributors, in less-expensive locations.
> The idea that we can choose less expensive locations is great, but I'm a
> little wary of focusing too much on "centers of mass of contributors", as
> it can easily become an excuse to have it in roughly the same places each
> time. As a non-USA based contributor, I really value the fact the the
> summits rotate around different regions instead of spending all the time
> in the USA as was the case earlier in openstcck days. Minimizing travel
> costs is no doubt a welcome aim for companies' budgets, but it should not
> be allowed to dominate to such a large extent that we miss representation
> of different regions. ie if we never went back to Asia because the it is
> cheaper for the /current/ majority of contributors to go to the US, we'll
> make it harder to attract new contributors from those regions we avoid on
> cost ground. The "center of mass of contributors" could become a self-
> fullfilling prophecy.
> IOW, I'm onboard with choosing less expensive locations, but would like
> to see us still make the effort to reach out across different regions
> for the events, and not become too US focused once again.

I agree with Dan here. Ensuring the events move around and go to
different contributors is very important in ensuring we hear new or
quiet voices.

I was surprised at the difference in how operators approach their
business in Europe as compared to the US and was glad to have the
experience to hear their voice. I would like to believe we have the
ability to continue to hold contributor events in different geographical

>> The split should ideally reduce the needs to organize separate in-person
>> mid-cycle events. If some are still needed, the main conference venue and
>> time could easily be used to provide space for such midcycle events (given
>> that it would end up happening in the middle of the cycle).
> The obvious risk with suggesting that current mid-cycle events could take
> place alongside the business conference, is that the "business conference"
> ends up being just as large as our combined conference is today.

I think the obstacles to listening at a large event, or co-located with
one, would be larger than any cost savings for using a spare room. The
trouble is it is hard to put a dollar amount on listening or an
environment that is conducive to listening.

My ability to listen is inversely proportional to the amount of people I
witness on any given day, regardless of whether they are in the room
with me or not. Smaller is better for my ability to listen.

Thank you,

> IOW we
> risk actually creating 4 big official developer events a year, instead of
> the current 2 events + small unofficial mid-cycles. You'd need to find some
> way to limit the scope of any "mid cycle" events that co-located with the
> business conference to prevent it growing out of hand.  We really want to
> make sure we keep the mid-cycles portrayed as optional small scale
> "hackathons", and not something that contributors feel obligated to
> attend. IMHO they're already risking getting out of hand - it is hard to
> feel well connected to development plans if you miss the mid-cycle events.
> Regards,
> Daniel

More information about the OpenStack-dev mailing list