Open Stack

On 29/02/16 10:32, "Thierry Carrez" <thierry at openstack.org> wrote:

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

This clarifies the situation. I agree that an ops branded event would have a stronger attraction (along with potential to be moved around more easily given the geographical diversity of deployments).

Thanks,
Tim

>
>-- 
>Thierry Carrez (ttx)
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160229/994f193a/attachment.bin>