Open Stack

Thierry and all of those who contributed to putting together this write-up, thank you very much.

TL;DR: +0

Longer version:

While I definitely believe that the new proposed timing for "OpenStack Summit" which is some months after the release, is a huge improvement, I am not completely enamored of this proposal. Here is why.

As a result of this proposal, there will still be four events each year, two "OpenStack Summit" events and two "MidCycle" events. The material change is that the "MidCycle" event that is currently project specific will become a single event inclusive of all projects, not unlike our current "Design Summit".

I contrast this proposal with a mid-cycle two weeks ago for the Trove project. Thanks to the folks at Red Hat who hosted us in Raleigh, we had a dedicated room, with high bandwidth internet and the ability to have people join us remotely via audio and video (which we used mostly for screen sharing). The previous mid-cycle similarly had excellent facilities provided us by HP (in California), Rackspace (in Austin) and at MIT in Cambridge when we (Tesora) hosted the event.

At these "simpler, scaled-back settings", would we be able to provide the same kind of infrastructure for each project?

Given the number of projects, and leaving aside high bandwidth internet and remote participation, providing dedicated meeting room for the duration of the MidCycle event for each project is a considerable undertaking. I believe therefore that the consequence is that the MidCycle event will end up being of comparable scale to the current Design Summit or larger, and will likely need a similar venue.

I also believe that it is important that OpenStack continue to grow not only a global customer base but also a global contributor base. As others have already commented, this proposal risks the "design summit" become US based, maybe Europe once in a long while. But I find it much harder to believe that these design summits would be truly global. And this I think would be an unwelcome consequence.

At the current OpenStack Summit, there is an opportunity for contributors, customers and operators to interact, not just in technical meetings, but also in a social setting. I think this is valuable, even though there seems to be a number of people who believe that this is not necessarily the case.

Those are the three concerns I have with the proposal. 

Thanks again to Thierry and all who contributed to putting this proposal together.

-amrith


> -----Original Message-----
> From: Thierry Carrez [mailto:thierry at openstack.org]
> Sent: Monday, February 22, 2016 10:14 AM
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [all] A proposal to separate the design summit
> 
> Hi everyone,
> 
> TL;DR: Let's split the events, starting after Barcelona.
> 
> Long long version:
> 
> In a global and virtual community, high-bandwidth face-to-face time is
> essential. This is why we made the OpenStack Design Summits an integral
> part of our processes from day 0. Those were set at the beginning of each
> of our development cycles to help set goals and organize the work for the
> upcoming 6 months. At the same time and in the same location, a more
> traditional conference was happening, ensuring a lot of interaction
> between the upstream (producers) and downstream (consumers) parts of our
> community.
> 
> This setup, however, has a number of issues. For developers first: the
> "conference" part of the common event got bigger and bigger and it is
> difficult to focus on upstream work (and socially bond with your
> teammates) with so much other commitments and distractions. The result is
> that our design summits are a lot less productive than they used to be,
> and we organize other events ("midcycles") to fill our focus and small-
> group socialization needs. The timing of the event (a couple of weeks
> after the previous cycle release) is also suboptimal: it is way too late
> to gather any sort of requirements and priorities for the already-started
> new cycle, and also too late to do any sort of work planning (the cycle
> work started almost 2 months ago).
> 
> But it's not just suboptimal for developers. For contributing companies,
> flying all their developers to expensive cities and conference hotels so
> that they can attend the Design Summit is pretty costly, and the goals of
> the summit location (reaching out to users everywhere) do not necessarily
> align with the goals of the Design Summit location (minimize and balance
> travel costs for existing contributors). For the companies that build
> products and distributions on top of the recent release, the timing of the
> common event is not so great either: it is difficult to show off products
> based on the recent release only two weeks after it's out. The summit date
> is also too early to leverage all the users attending the summit to gather
> feedback on the recent release -- not a lot of people would have tried
> upgrades by summit time. Finally a common event is also suboptimal for the
> events organization : finding venues that can accommodate both events is
> becoming increasingly complicated.
> 
> Time is ripe for a change. After Tokyo, we at the Foundation have been
> considering options on how to evolve our events to solve those issues.
> This proposal is the result of this work. There is no perfect solution
> here (and this is still work in progress), but we are confident that this
> strawman solution solves a lot more problems than it creates, and balances
> the needs of the various constituents of our community.
> 
> The idea would be to split the events. The first event would be for
> upstream technical contributors to OpenStack. It would be held in a
> simpler, scaled-back setting that would let all OpenStack project teams
> meet in separate rooms, but in a co-located event that would make it easy
> to have ad-hoc cross-project discussions. It would happen closer to the
> centers of mass of contributors, in less-expensive locations.
> 
> More importantly, it would be set to happen a couple of weeks /before/ the
> previous cycle release. There is a lot of overlap between cycles.
> Work on a cycle starts at the previous cycle feature freeze, while there
> is still 5 weeks to go. Most people switch full-time to the next cycle by
> RC1. Organizing the event just after that time lets us organize the work
> and kickstart the new cycle at the best moment. It also allows us to use
> our time together to quickly address last-minute release-critical issues
> if such issues arise.
> 
> The second event would be the main downstream business conference, with
> high-end keynotes, marketplace and breakout sessions. It would be
> organized two or three months /after/ the release, to give time for all
> downstream users to deploy and build products on top of the release. It
> would be the best time to gather feedback on the recent release, and also
> the best time to have strategic discussions: start gathering requirements
> for the next cycle, leveraging the very large cross-section of all our
> community that attends the event.
> 
> To that effect, we'd still hold a number of strategic planning sessions at
> the main event to gather feedback, determine requirements and define
> overall cross-project themes, but the session format would not require all
> project contributors to attend. A subset of contributors who would like to
> participate in this sessions can collect and relay feedback to other team
> members for implementation (similar to the Ops midcycle).
> Other contributors will also want to get more involved in the conference,
> whether that's giving presentations or hearing user stories.
> 
> The split should ideally reduce the needs to organize separate in-person
> mid-cycle events. If some are still needed, the main conference venue and
> time could easily be used to provide space for such midcycle events (given
> that it would end up happening in the middle of the cycle).
> 
> In practice, the split means that we need to stagger the events and
> cycles. We have a long time between Barcelona and the Q1 Summit in the US,
> so the idea would be to use that long period to insert a smaller cycle
> (Ocata) with a release early March, 2017 and have the first specific
> contributors event at the start of the P cycle, mid-February, 2017. See
> the attached PDF for a visual explanation. With the already-planned events
> in 2016 and 2017 it is the earliest we can make the transition. We'd have
> a last, scaled-down design summit in Barcelona to plan the shorter cycle.
> 
> With that setup, we hope that we can restore the productivity and focus of
> the face-to-face contributors gathering, reduce the need to have midcycle
> events for social bonding and team building, keep the cost of getting all
> contributors together once per cycle under control, maintain the feedback
> loops with all the constituents of the OpenStack community at the main
> event, and better align the timing of each event with the reality of the
> release cycles.
> 
> NB: You will note that I did not name the separated event "Design Summit"
> -- that is because Design will now be split into feedback/requirements
> gathering (the "why" at the main event) and execution planning and
> kickstarting (the "how" at the contributors-oriented event), so that name
> doesn't feel right anymore.
> We can bikeshed on the name for the new event later :)
> 
> Comments, thoughts ?
> 
> --
> Thierry Carrez (ttx)