[Openstack] Bringing focus to the Operators and Users at the next summit
Matt Van Winkle
mvanwink at rackspace.com
Mon Dec 23 14:56:03 UTC 2013
Good points Mark. And to several of the other comments made this weekend, I think that mid-cycle is indeed better. Not only does it avoid the cram-packed design summit, it allows those of us with access to Core/key developers in our own organizations to help push change after the user/operators have collected their thoughts and leading up to the next summit.
Also, whether in conjunction with other non-Openstack conferences or not, these chats don't have to be a single event – we could have a few mid-cycle conversations based on region or user type. It would just require some extra co-ordination, correlation, etc, but if we are generating outputs like a weighted priority list, etc, we'll have solved for a lot of these things anyway.
Thanks!
Matt
From: Mark Collier <mark at collierclan.net<mailto:mark at collierclan.net>>
Date: Monday, December 23, 2013 7:29 AM
To: Sean Dague <sean at dague.net<mailto:sean at dague.net>>
Cc: "openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>" <openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>>
Subject: Re: [Openstack] Bringing focus to the Operators and Users at the next summit
Thanks Sean. You and Thierry have made great points on this thread that I think give people more insight into the process and timing required to really impact the releases.
I've fallen into the trap many times of thinking we can solve any problem in the world during the 10 days a year we are all together, but in the end its only 10 days. No matter how you organize them, they don't any get longer.
So +1 for some activities well before the summit to gather input. I think Tim's suggestion makes a ton of sense.
IMHO we should also avoid the trap of thinking that for gatherings to be valuable "everyone has to be there". That's what leads back to thinking the summit weeks are the answer to everything. As Tim said, it's quite likely operators are experiencing a lot of the same pain points, so what is needed is critical mass and action, not every known user in one room (unrealistic). Perhaps with some online components where operators that couldn't make a meetup can weigh in (and give a weighted priority to a list?)
On Dec 23, 2013 6:35 AM, "Sean Dague" <sean at dague.net<mailto:sean at dague.net>> wrote:
On 12/22/2013 12:49 PM, Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com> wrote:
> I’d like to repeat a suggestion at the Design Summit wrap up – it’s a
> bit different, so patience…
>
>
>
> My suggestion was to insert a day “break” into the four day Design
> Summit for users/operations. Effectively, we’d have a four day design
> summit with Monday+Tuesday - break for user/ops conf –
> Thursday+Friday. This would allow the developers and PTLs to join in
> the conference parts of the summit without needed a distinct event.
> The regular non-design conference could be held Tuesday-Thursday so
> there’s a specific overlap day when 100% of the community would be together.
>
>
>
> I felt like this allows ideas from the summit to be socialized with
> users/operator before we commit to them. I also felt that it makes the
> developers more accessible. Finally, it creates a break/reflection from
> the intensity of the design.
>
>
>
> To recap, 4 day design, 3 day user/ops conference spanning 5 days.
Honestly I'd be pretty -1 on that idea. There is a certain momentum that
builds inside the design summit sessions that 2 hard context switches
like that would really hurt. If you've ever spent time in the Nova track
you can see this in spades.
I think one of the missing things for folks that don't spend all their
time in Design Summit is realizing that DS is really the *middle* of the
conversation, not that start of one. I actually think this is where
folks new to design summit tend to flail a little be in their sessions.
My goals for design summit, and my tracks, were set weeks in advance,
and there was very little new here, it was mostly about working through
the sticky details on things we largely were already working on, and
exposing some of that work to a wider audience which drags in new
volunteers. So the User / Ops day at Summit is far too late to impact
that release cycle.
That interaction needs to come 3+ weeks before Design Summit to be
effective on that cycle. Because if it's later than that, it's just too
much to digest at a point where the plates are already overflowing. The
key developers are already about 200% booked at Summits at this point,
which is actually why *more* OpenStack PTLs spoke at LinuxCon NA this
year than at OpenStack Summit HK. For instance, I only wandered out side
of Design Summit twice, when I was on stage. And I didn't even get a
chance to go to any of the public parties, as I was booked every single
night at summit - weeks in advance.
So I think that all those folks are pretty open to getting more engaged
with Users / Ops (I know I am), but the existing Summit structure isn't
going to allow that. Making people 250% booked at Summit isn't going to
really be a successful way to handle this.
I'm far more positive on something mid cycle, preferably at other
conferences that we expected there to be OpenStack folks at to begin with.
-Sean
--
Sean Dague
Samsung Research America
sean at dague.net<mailto:sean at dague.net> / sean.dague at samsung.com<mailto:sean.dague at samsung.com>
http://dague.net
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/1929d26c/attachment.html>
More information about the Openstack
mailing list