On 29/02/16 10:32, "Thierry Carrez" <thie...@openstack.org> wrote:
>Tim Bell wrote: >> >> On 26/02/16 18:08, "Thierry Carrez" <thie...@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-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
