Open Stack

On 02/23/2016 04:26 PM, 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.
> 

My initial concern would be: "Crap, now I have to go to four events
instead of two."

However, a more serious concern I have would be that this would, over
time, remove the community aspects from the main conference, making it
increasingly corporate, and less upstream-focused, over time. That would
be  loss, from my perspective. One of the advantages of the current
format is that we get to highlight the Open Source community aspects of
OpenStack to the people who may otherwise only think of selling product.

On the other hand, there are some big advantages to this approach, as
identified by both you and Thierry. And I'm sure that, given the quality
of events that y'all have done to date, that you'll make this work, too.



>> 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 <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)
>>>
>>>
>>> _______________________________________________
>>> Marketing mailing list
>>> Marketing at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
>>>
>>
>> -- 
>> Dave Neary - NFV/SDN Community Strategy
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
>>
>> _______________________________________________
>> Marketing mailing list
>> Marketing at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
> 
> 
> _______________________________________________
> Marketing mailing list
> Marketing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing
> 


-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://rdoproject.org/