[openstack-dev] [all] A proposal to separate the design summit
sbauza at redhat.com
Mon Feb 29 09:19:36 UTC 2016
Honestly, it took me a while before having an opinion on that subject.
Le 26/02/2016 18:08, Thierry Carrez a écrit :
> Thierry Carrez wrote:
>> 1. "Two trips instead of one"
>> There is a section of attendees which benefited from a single event:
>> in-between people who do not generally go to any midcycle events and
>> successfully split their attention between the design summit and the
>> main conference when they were overlapping. Those people fear that in
>> order to keep the same benefits they will have to travel to two events
>> per cycle instead of one.
>> 2. Community split
>> There is fear that the contributor-specific event will separate the
>> community into two groups, with developers skipping the main event and
>> non-developers not providing any feedback to the contributor-specific
> For those two objections, it's worth noting that there will still be a
> lot of strategic discussions at the main event. That is where we look
> at the N-1 release and start drawing plans and cross-project themes
> for the N+1 release. We don't need every developer there, but we still
> need a significant chunk of them, with every team represented, so that
> we can have those strategic and cross-project discussions.
> Therefore I'd expect someone who wants to keep touch with development
> could still make only one trip, and I wouldn't expect the communities
> to be split. We'd still all be represented in the main event.
While I think some top-notch skilled OpenStack developers would still be
able to attend both events, it would leave a huge number of non-core and
other non-verbal developers to pick between the DevEvent and the Summit.
Given that, it would certainly decrease the capacity for those
developers to be part of the community feedback and feature gathering
that we try to achieve at Summit time.
>> 3. Losing the main summit as an excuse to fund devs travel
>> Some developers are sent to the Design Summit only because the main
>> summit is happening at the same time and wouldn't get funding to attend
>> a specific event.
> If you have to pretend to attend the Summit to be able to attend the
> Design Summit instead, there is deception involved. I'd suggest to
> have a frank talk with your employer on where the most value lies for
> you in attending which event. We also have the Travel support program
> to cover the gaps.
Well, not all companies are platinum or gold Foundation sponsors and
some are contributing to OpenStack with very little budget commitment
apart human resources.
While one could claim the opportunity to ask their company to increase
their budget, my guts is that the vast majority will just be unable to
get that and will be veto'ed.
We also know that the Travel Support Program is not scalable. Even if
the Austin budget for this is doubled, it couldn't cope with all
developers wanting to attend the main Summit - because they're also
interested in Ops.
>> 4. The fear of US-centricity
>> A lot of people translated "closer to the centers of mass of
>> contributors" as meaning "happening in the US all the time". That would
>> indeed reduce the total travel costs, but at the expense of making it a
>> lot more costly for non-US parts of our community to participate.
> That is a real concern. The goal is to "minimize and balance travel
> costs for existing contributors"... notice the word "balance": there
> would still be some continent rotation involved. The trick will be to
> strike the right balance between cost and fairness.
>> 5. The loss of the midcycle spirit
>> Last but not least, some people really like the midcycles as they stand:
>> separated small events where only your small team is around. The split
>> appears to reduce the likelihood, the need, or the funding for such
>> events. Even if we keep the midcycle laid-back format in the new event,
>> co-locating them would turn it into a large event and we'd lose some of
>> the focus or some of the "only us around" aspect.
> While I hope the proposed format will let us fulfill all our team
> socialization needs, it's true that there will be other people around,
> and it will feel a lot less exclusive and special. The trade-off is
> that having people all together encourages cross-project work and
> breaks silos. Hopefully we'll strike the right balance there that will
> let us all get most of the productivity of the current midcycles. It's
> also worth noting that the proposal doesn't prevent team-specific
> events from happening. So if for any reason people don't get what they
> need from the new event, I suspect we'll still have midcycles around
> and that will be a strong signal that we need to tweak the whole thing
Count me in for saying how those existing face-to-face midcycles are
extremely productive and I'm really not sure virtual sprints could
achieve the same. I'm also convinced that midcycles are not extremely
productive because Design Summits aren't, but rather because for some
projects, it's growing extremely fast and it's hard to wait 6 months for
synchronizing all efforts.
I'm not opiniated on whether those midcycles should be hosted during
Summits. That said, if we assume to have those being hosted independtly,
it would litterally be impossible for devs to attend Summits (because it
would mean 3 travels per cycle).
That would lock any decision-making we could do about the midcycle
location, because we couldn't honeslty claim for an independent location
if we know we're making life harder for our contributors.
To be honest, I see two problems :
- developers being distracted during Design Summits to attend some
company matters is certainly a problem, and we should probably ask our
employers to balance that rather than trying to split Design Summits for
- Schedule is not perfect with Summit being far too close to the
release date, but that's only a problem for operators wanting to
showcase their product - not developers. Why the Design Summit should be
impacted then ? It's pretty clear for developers wanting to contribute
that we open the release cycle 4 weeks before the Summit, and it even
allows reviewers to look at specifications before being face-to-face for
getting an agreement.
More information about the OpenStack-dev