Open Stack

Tim Bell wrote:
>
> On 26/02/16 18:08, "Thierry Carrez" <thierry at openstack.org> wrote:
>>>
>>> 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.
>
> Is the assumption that the users would be at the summit rather than the contributor-specific sessions ? As there is a lot of sharing going on in the current summit format (it is not just talks on products), I think the cloud consumers/deployers would tend towards the summit.
>
> I think this is my biggest worry that we get to a scenario where we lose the chance for user (be it consumer of clouds or operators) technical discussion with the projects. It certainly does not need all developers to be present but project presentation at a high level is needed to understand the requirements, explain the reasons for design decisions and debate the appropriate improvements.

I think your worry is due to a misconception. We don't move the "design 
summit" to a separate event and remove the users from the equation. We 
*split* the design summit into two steps: strategic and tactical. Let's 
take the Q cycle as an example (you can refer back to the picture I 
attached to the original post).

It starts at the US Summit in May, 2017. We have everyone there: users, 
product managers, but also a significant share of devs: PTLs, TC members 
and other cross-project liaisons and drivers. The Ocata release has been 
out for a few months and operators have started deploying and upgrading 
to it. In the Strategic planning sessions, users can give feedback to 
devs about that Ocata release and how the upgrade goes. We can start 
drawing overarching themes for the Q cycle to address the pain points. 
We can start prioritizing features and discuss their requirements and 
initial design points. We can discuss user-facing policies like API 
deprecation rules, stable branch maintenance, vulnerability 
management... We make the most of the presence at the main summit event 
to get all the community together.

In August, 2017 we have the Q contributor-oriented event. By that date 
we have the feedback, we have the requirements, we have the priorities. 
The problem is in getting things done. Teams gather and make sure they 
have assignees for everything, and that all gaps are covered. They 
discuss how to get a specific feature into the code, bootstrap the work, 
and solve potential conflicts. They decide on meeting frequency, patch 
review days, cross-project liaisons. We need *all* the regular 
developers there so that everyone agrees on the plan to execute and 
follow. Users are still welcome, but this is not a space for discussion 
and influencing the priorities: it's a space to get things done and get 
tactical alignment on how to achieve it in the next 3 months.

In November, 2017 we have the next summit, probably in APAC. Some 
specific priority feature in a given project is not getting implemented 
fast enough and is at risk. That project team decides to take advantage 
of the summit space to hold a one-day hackathon to get this feature back 
on track.

Early March, 2018 the Q release cycle is completed.

> With the offset of the two event, has an option to locate the operators mid-cycle meetup at the contributor-specific event ?

That was considered... and I would not necessarily be against it, but I 
would like to understand what the benefit would be. Tom advocated for 
keeping it as a separate event (or a set of regional separated events) 
that would be ops-branded, making it easier for ops to justify travel to 
it. If the goal is to co-locate so that users can more easily 
participate to the contributor-oriented event, I think that would be 
counter-productive for most operators: as I said earlier those are 
project team meetings for project team members to work together -- you 
should only join a room if you consider yourself part of the team that 
will do the work. We won't be rediscussing requirements or gathering 
feedback there, those will have been discussed at the strategic planning 
sessions at the summit already.

-- 
Thierry Carrez (ttx)