Open Stack

On Sun, Feb 07, 2016 at 03:07:20PM -0500, Jay Pipes wrote:
> I would love to see the OpenStack contributor community take back the design
> summit to its original format and purpose and decouple it from the OpenStack
> Summit's conference portion.
> 
> I believe the design summits should be organized by the OpenStack
> contributor community, not the OpenStack Foundation and its marketing and
> event planning staff. This will allow lower-cost venues to be chosen that
> meet the needs only of the small group of active contributors, not of huge
> masses of conference attendees. This will allow contributor companies to
> send *more* engineers to *more* design summits, which is something that
> really needs to happen if we are to grow our active contributor pool.
> 
> Once this decoupling occurs, I think that the OpenStack Summit should be
> renamed to the OpenStack Conference and Expo to better fit its purpose and
> focus. This Conference and Expo event really should be held once a year, in
> my opinion, and continue to be run by the OpenStack Foundation.
> 
> I, for one, would welcome events that have no conference check-in area, no
> evening parties with 2000 people, no keynote and powerpoint-as-a-service
> sessions, and no getting pulled into sales meetings.
> 
> OK, there, I said it.
> 
> Thoughts? Criticism? Support? Suggestions welcome.

I really agree with everything you say, except for the bit about the
community doing organization - I think its fine to let function event
staff continue with the burden of planning, as long as their goals are
directed by the community needs.

I might suggest that we could be a bit more radical with the developer
event and decouple the timing from the release cycle. The design summits
are portrayed as events where we plan the next 6 months of work, but the
release has already been open for a good 2-3 or more weeks before we meet
in the design summit. This always makes the first month of each development
cycle pretty inefficient as decisions are needlessly postponed until the
summit. The bulk of specs approval then doesn't happen until after the
summit, leaving even less time until feature freeze to get the work done.

In nova at least many of the major "priority themes" we decide upon are
tending to span across multiple development cycles, and we broadly seem
to have a good understanding of what the upcoming themes will be before
we get to the summit. The other problem with the design summit is that
since we have not often started the bulk of the dev work, we don't yet
know all the problems we're going to encounter. So we can talk forever
about theoretical stuff, which never becomes an issue and the actual
problems we uncover during implementation have to wait until the mid-cycle
for the real problem solving work. IOW I'm not really convinced we actually
need to have the design summit as a forum for "planning the next release"
nor is it enourmously useful for general problem solving, since it can be
too earlier in the dev process.

I think that our processes would become more efficient if we were to
decouple the design summit from the release cycle. We would be able to
focus on release planning right from the start of the dev cycle and not
pointlessly postpone decisions to a design summit, which would give us
more time to actually get the planned work written earlier in the cycle.

This would in turn let us make the developer summits into something which
strongly focuses on problem solving, where f2f collaboration is of maximum
benefit. IOW, it would be kind of like merging the design summit & midcycle
concepts into one - we'd have the benefits of the mid-cycle's focus on
explicit problem solving, combined with the ability to have cross-project
collaboration by being co-located with other projects. Instead of having
4 travel events a year, due to need to fix at 6 month intervals to align
with the release schedules, we could cut down to 2 or 3 developer events
a year, which are more productive overall.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|