Open Stack

Hi Lauren,

For whatever it's worth, here's how I see this from the perspective of
impact on our engineering team:

  * The contributor events should be more productive; the timing is 
    much more conducive to planning the next cycle, as opposed to
    currently where development for the next cycle is well underway

  * Many of our contributors are traveling to mid-cycles meetups, 
    anyway

  * We expect a much, much smaller number of our engineers will be
    needed for the main conferences - only upstream leaders, engineers 
    with talks accepted, those needed for customer/partner meetings, 
    any needed for booth duty, etc.

  * The main conference is being pushed out further, so we should be 
    in a better position to talk our latest product release at that
    time

  * The idea seems to be to have an event every 3 months, which
    actually isn't terrible for those few who do need to travel to
    all of them ... they're doing something similar now, anyway.

A very positive change!

Thanks,
Mark.

On Tue, 2016-02-23 at 15:26 -0600, Lauren Sell wrote:
> Hi Dave, Frank,
> 
> Thanks for providing feedback, it’s definitely welcome. No decision
> has been made. I completely agree that bringing together developers,
> users and the ecosystem to one event creates a very unique experience
> and productive environment. 
> 
> The proposal was in response to a thread on the dev mailing list that
> has been percolating for some time. We are planning to discuss it in
> the board meeting, which is starting now. Based on initial response
> and feedback from the Board, we will firm up our thoughts and will
> definitely be seeking more feedback. IF we decide to make any
> changes, they would not go into effect until 2017 or beyond.
> 
> One thing to note is that the current proposal would not pull out the
> Design Summit in its entirety. With the growing community and
> increasing number of projects, the Design Summit has become very busy
> and highly parallelized. The proposal would keep the more strategic
> and user-centric  “why” discussions at the Summit and direct the more
> tactical “how” implementation discussions into the separate event. In
> practice, this would be more like 4 parallel tracks in the design
> summit rather than 12-16, so more developers can participate in cross
> project and higher level discussions. 
> 
> There are many details that would need to be discussed and decided,
> but at a high level we would still expect a good number of
> contributors to attend the main event, as well as discussions to
> happen around release planning and the future of the project. Ideally
> a scaled back design summit would also give contributors more freedom
> to present and participate in the conference.
> 
> Again, all feedback is welcome. We’ve received very positive feedback
> on the Summit to date and do not take any changes lightly. We are
> just looking to best serve and balance the needs of all of our
> constituents as the Summit and community continues to grow.
> 
> Best,
> Lauren
> 
> 
> > On Feb 23, 2016, at 1:28 PM, Dave Neary <dneary at redhat.com> wrote:
> > 
> > Hi,
> > 
> > Considering the source, this looks like it is very seriously being
> > considered. I would go so far as to say it sounds like it is already in
> > planning.
> > 
> > The only down-side I can see is that some members of the community would
> > now be compelled to travel to 2 events per release cycle. But for most
> > participants, this proposal will convert the main Summit into an
> > optional event for developers, and a requirement for product, bizdev,
> > sales, marketing teams.
> > 
> > I await the outcome of the discussion - I will forward on the thread to
> > our product and marketing teams in here to see what they think (given
> > MWC this week, response time from them may be slow).
> > 
> > Thanks,
> > Dave.
> > 
> > 
> > On 02/23/2016 01:01 PM, Frank  Days wrote:
> > > 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 >
> > > > 
> > > > 
> > > > 
> > > > On 2016-02-22, 10:14 AM, "Thierry Carrez" 
> > > > 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)
> > > 
> > > 
> > > _______________________________________________
> > > Marketing mailing list
> > > Marketing at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
> > > 
> >