Open Stack

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
>> event.
>
> 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 
> again.
>

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 
that sake
  - 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.

-Sylvain