[openstack-dev] [all] A proposal to separate the design summit

Antoni Segura Puimedon toni+openstackml at midokura.com
Fri Feb 26 10:41:55 UTC 2016


On Fri, Feb 26, 2016 at 10:44 AM, Miguel Angel Ajo Pelayo
<majopela at redhat.com> wrote:
>
>> On 26 Feb 2016, at 02:38, Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>>
>> On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote:
>>> Hi, All,
>>>
>>> After reading through all the +1's and -1's, we realized how difficult
>>> it is to come up with a proposal that makes everyone happy. When we are
>>> discussing this proposal with some other contributors, we came up with a
>>> proposal which is a little bit different. This idea could be very
>>> impractical, very naive, given that we don't know much about the huge
>>> efforts behind the scheduling, planning, coordination ... etc etc. So,
>>> please treat this as a random thought.
>>>
>>> Maybe we can still have the Summit and the Design Summit colocated, but
>>> we can avoid the overlap that has been the source of many troubles. The
>>> idea is to have both events scheduled by the end of a release cycle. For
>>> example:
>>>
>>> Week 1:
>>>  Wednesday-Friday: 3 days Summit.
>>>    * Primarily an event for marketing, sales, CTOs, architects,
>>>      operators, journalists, ...
>>>    * Contributors can decide whether they want to attend this.
>>>  Saturday-Sunday:
>>>    * Social activities: contributors meet-up, hang outs ...
>>>
>>> Week 2:
>>>  Monday-Wednesday: 3 days Design Summit
>>>    * Primarily an event for developers.
>>>    * Operators can hold meetups during these days, or join project
>>>      design summits.
>>>
>
>
> A proposal like this one seems much more rational to me,
>
>   * no need for two trips
>   * no overlap of the summit/design (I end up running back and forth otherwise)

These. A thousand times these. Yes, I know the timing in the cycle is still
not the best, but I suspect that with the other option project
specific mid-cycles
will still occur.

>
> Otherwise, separating both parts of the summit increases the gap
> between engineering and the final OpenStack users/ops. I couldn’t go
> to summit-related-events 4 times a year for family reasons. But I like
> to have the opportunity to spend some time close to the user/op side
> of things to understand how people is using OpenStack, what are they
> missing, what are we doing good.
>
>
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>>
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>>>
>>> Thoughts?
>
> I really like it. Not sure how well does it work for others, or from
> the organisational point of view.

Probably a big issue is that organizers would end up losing 2-3 weekends
in a row, which may be a bit too much to ask.

>
>>>
>>> - Qiming
>>>
>>
>> This would eliminate the need for a second flight, and it would
>> net be total less time away than attending two separate events. I could
>> see this working.
>>
>> Sean
>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list