Open Stack

The following thread has been making the rounds in the Dev list and I wanted to reshare it here on the marketing list.

As a Summit sponsor, we have been very happy with the existing format and have concerns about the potential impact splitting Summit into two events.

Anyone know if this a just straw man or something that is getting serious consideration?

Thanks,
Frank Days







Frank Days | VP, Marketing

Direct: +1.978.707.8010 ext. 1017
frank.days at tesora.com<mailto:frank.days at tesora.com> | @tangyslice | Skype: fmdays
125 CambridgePark Drive, Suite 400, Cambridge, MA 02140




Begin forwarded message:

Subject: FW: [openstack-dev] [all] A proposal to separate the design summit
Date: February 22, 2016 at 10:27:39 AM EST
To: "Frank Days" <frank.days at tesora.com<mailto:frank.days at tesora.com>>



On 2016-02-22, 10:14 AM, "Thierry Carrez" <thierry at openstack.org<mailto:thierry at openstack.org>> wrote:

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/cgi-bin/mailman/private/marketing/attachments/20160223/1bba7e0c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: events.pdf
Type: application/pdf
Size: 23306 bytes
Desc: events.pdf
URL: <http://lists.openstack.org/cgi-bin/mailman/private/marketing/attachments/20160223/1bba7e0c/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/cgi-bin/mailman/private/marketing/attachments/20160223/1bba7e0c/attachment-0001.htm>