Open Stack

On Wed, Aug 13, 2014 at 09:18:09AM -0700, Maru Newby wrote:
> 
> On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
> >> Hi.
> >> 
> >> One of the action items from the nova midcycle was that I was asked to
> >> make nova's expectations of core reviews more clear. This email is an
> >> attempt at that.
> >> 
> >> Nova expects a minimum level of sustained code reviews from cores. In
> >> the past this has been generally held to be in the order of two code
> >> reviews a day, which is a pretty low bar compared to the review
> >> workload of many cores. I feel that existing cores understand this
> >> requirement well, and I am mostly stating it here for completeness.
> >> 
> >> Additionally, there is increasing levels of concern that cores need to
> >> be on the same page about the criteria we hold code to, as well as the
> >> overall direction of nova. While the weekly meetings help here, it was
> >> agreed that summit attendance is really important to cores. Its the
> >> way we decide where we're going for the next cycle, as well as a
> >> chance to make sure that people are all pulling in the same direction
> >> and trust each other.
> >> 
> >> There is also a strong preference for midcycle meetup attendance,
> >> although I understand that can sometimes be hard to arrange. My stance
> >> is that I'd like core's to try to attend, but understand that
> >> sometimes people will miss one. In response to the increasing
> >> importance of midcycles over time, I commit to trying to get the dates
> >> for these events announced further in advance.
> > 
> > Personally I'm going to find it really hard to justify long distance
> > travel 4 times a year for OpenStack for personal / family reasons,
> > let alone company cost. I couldn't attend Icehouse mid-cycle because
> > I just had too much travel in a short time to be able to do another
> > week long trip away from family. I couldn't attend Juno mid-cycle
> > because it clashed we personal holiday. There are other opensource
> > related conferences that I also have to attend (LinuxCon, FOSDEM,
> > KVM Forum, etc), etc so doubling the expected number of openstack
> > conferences from 2 to 4 is really very undesirable from my POV.
> > I might be able to attend the occassional mid-cycle meetup if the
> > location was convenient, but in general I don't see myself being
> > able to attend them regularly.
> > 
> > I tend to view the fact that we're emphasising the need of in-person
> > meetups to be somewhat of an indication of failure of our community
> > operation. The majority of open source projects work very effectively
> > with far less face-to-face time. OpenStack is fortunate that companies
> > are currently willing to spend 6/7-figure sums flying 1000's of
> > developers around the world many times a year, but I don't see that
> > lasting forever so I'm concerned about baking the idea of f2f midcycle
> > meetups into our way of life even more strongly.
> 
> I was fortunate to attend both the Nova and Neutron mid-cycles last
> month, and I can attest to how productive these gatherings were.
> Discussion moved quickly and misunderstandings were rapidly resolved.
> Informal ('water-cooler') conversation led to many interactions that
> might not otherwise have occurred.  Given your attendance of summit
> and other open source conferences, though, I'm assuming the value of
> f2f is not in question.

I'm not questioning the value of f2f - I'm questioning the idea of
doing f2f meetings sooo many times a year. OpenStack is very much
the outlier here among open source projects - the vast majority of
projects get along very well with much less f2f time and a far
smaller % of their contributors attend those f2f meetings that do
happen. So I really do question what is missing from OpenStack's
community interaction that makes us believe that having 4 f2f
meetings a year is critical to our success.

> Nothing good is ever free.  The financial cost and exclusionary
> nature of an in-person meetup should definitely be weighed against
> the opportunity for focused and high-bandwidth communication.  It's
> clear to myself and other attendees just how valuable the recent
> mid-cycles were in terms of making technical decisions and building
> the relationships to support their implementation.  Maybe it isn't
> sustainable over the long-term to meet so often, but I don't think
> that should preclude us from deriving benefit in the short-term.

As pointed out this benefit for core devs has a direct negative
impact on other non-core devs. I'm questioning whether this is
really a net win overall vs other approaches to collaboration.

> I also don't think we should ignore the opportunity for more
> effective decision-making on the grounds that not everyone
> can directly participate.  Not everyone is able to attend
> summit, but it is nonetheless a critical part of our
> community's decision-making process.  The topic lists for a
> mid-cycle are published beforehand, just like summit, to
> allow non-attendees the chance to present their views in
> advance and/or designate one or more attendees to advocate
> on their behalf.  It's not perfect, but the alternative -
> not holding mid-cycles - would seem to be a case of throwing
> out the baby with the bathwater.

As I explain in the rest of my email below I'm not advocating
getting rid of mid-cycle events entirely. I'm suggesting that
we can attain a reasonable % of the benefits of f2f meetings
by doing more formal virtual meetups and so be more efficient
and inclusive overall.

> > 
> >> Given that we consider these physical events so important, I'd like
> >> people to let me know if they have travel funding issues. I can then
> >> approach the Foundation about funding travel if that is required.
> > 
> > Travel funding is certainly an issue, but I'm not sure that Foundation
> > funding would be a solution, because the impact probably isn't directly
> > on the core devs. Speaking with my Red Hat on, if the midcycle meetup
> > is important enough, the core devs will likely get the funding to attend.
> > The fallout of this though is that every attendee at a mid-cycle summit
> > means fewer attendees at the next design summit. So the impact of having
> > more core devs at mid-cycle is that we'll get fewer non-core devs at
> > the design summit. This sucks big time for the non-core devs who want
> > to engage with our community.
> > 
> > Also having each team do a f2f mid-cycle meetup at a different location
> > makes it even harder for people who have a genuine desire / need to take
> > part in multiple teams. Going to multiple mid-cycle meetups is even more
> > difficult to justify so they're having to make difficult decisions about
> > which to go to :-(
> > 
> > I'm also not a fan of mid-cycle meetups because I feel it further
> > stratifies our contributors into two increasly distinct camps - core
> > vs non-core.
> > 
> > I can see that a big benefit of a mid-cycle meetup is to be a focal
> > point for collaboration, to forcably break contributors our of their
> > day-to-day work pattern to concentrate on discussing specific issues.
> > It also obviously solves the distinct timezone problem we have with
> > our dispersed contributor base. I think that we should be examining
> > what we can achieve with some kind of virtual online mid-cycle meetups
> > instead. Using technology like google hangouts or some similar live
> > collaboration technology, not merely an IRC discussion. Pick a 2-3
> > day period, schedule formal agendas / talking slots as you would with
> > a physical summit and so on. I feel this would be more inclusive to
> > our community as a whole, avoid excessive travel costs, so allowing
> > more of our community to attend the bigger design summits. It would
> > even open possibility of having multiple meetups during a cycle (eg
> > could arrange mini virtual events around each milestone if we wanted)

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 :|