Open Stack

confirmed

On 07/10/14 12:47 PM, Zane Bitter wrote:
> Greetings OpenStackers,
> I would like to announce my candidacy for the OpenStack Technical
> Committee.
> 
> I have worked closely with the TC since around the time that Heat was
> incubated, two years ago. I have been a regular participant in TC
> meetings throughout the Juno cycle as the Heat PTL, so I am familiar
> with the current structures and procedures, their back-story, and the
> issues that are before the committee.
> 
> I think I can best contribute by digging deep into issues, rooting out
> the points of contention or misunderstanding and building consensus from
> there. If you follow openstack-dev closely you'll probably have seen me
> doing that quite a bit already. I don't claim to have all the answers,
> but I'm pretty good at asking questions.
> 
> The OpenStack project has been incredibly successful in building a
> strong community where people want to collaborate on solving problems
> for our common users.[1] We are at a point where we need to readjust the
> structure of the project to better respond to the next phase of that
> success. This is not the first time we have reached such a point; nor
> will it be the last. There is no final form of the OpenStack project; we
> must approach it as we would any engineering problem (_not_, I hasten to
> add, a technical problem): by considering our goals and opportunities,
> making incremental changes, evaluating their effects (both intended and
> unintended), and repeating.
> 
> I believe we need to work to reduce entropy in the OpenStack system -
> encouraging shared components and implementations over repeatedly
> reinventing the wheel - without crushing innovation. Those two goals are
> in tension (note that the wheel has been repeatedly reinvented
> throughout history, often to great effect), but they are the ones I will
> be trying to balance. And we must, of course, do this while giving
> operators and end-users confidence in their investments in the OpenStack
> ecosystem.
> 
> I think making it easier for projects to join the OpenStack community
> would be a good thing, provided that still entails a commitment to doing
> things the OpenStack way backed up by meaningful oversight by the TC.
> I'm comfortable for now with leaving a high bar for graduation in place,
> though it needs to move around less. While I am in favour of more
> projects in principle, I'll be scrutinising specific projects carefully
> to make sure that they've either been able to apply the feedback part of
> the engineering process I described above with real users, or
> alternatively have solved the simplest possible version of their design
> problem with a view to maximising their flexibility to respond when they
> do get that feedback.[2]
> 
> What we're really missing are stepping stones from the lower incubation
> bar to the high graduation bar. We need to do more to help projects
> understand how they can fit in to the bigger picture and what they need
> to do to get there.
> 
> That will require greater involvement from the TC, but it appears we
> have already reached the point where the TC itself does not scale. That
> was evident from the Zaqar's second graduation review. One year after
> its incubation, the TC was still debating whether an SQS-like cloud
> messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint:
> none of them[4]), and in the end deferred for another six months to
> figure it out. It's clear that TC members don't have the time to dig
> deeply into all the issues that cross their desks. I already proposed a
> structure whereby subcommittees in each general subject area, comprising
> a representative from each of the relevant projects plus one TC member,
> would do the investigation and mentoring of new projects and report the
> results to the TC.[5] In this model the TC would be responsible for
> setting an overall vision for the project and ensuring that it is
> applied consistently. I would welcome other proposals that could help to
> expand and deepen support for new projects in a way that can scale
> through our next stage of growth. (I am also a strong supporter of
> having formal liaison programs to boost the impact of horizontal,
> cross-project functions without stretching them to breaking point.[1])
> 
> As we're figuring out structural changes I think we need to be careful
> to decouple short-term technical issues, like how to scale the gate to a
> larger number of projects that don't all have mutual dependencies, from
> longer-term structural issues. We also need to be very aware of how
> changes we make might be perceived by external parties not sharing the
> same context, including the Foundation Board and especially the DefCore
> subcommittee. Finally, we need to remember that our users see the cloud
> from many different perspectives and that no single perspective can
> capture what is important to our community.[5]
> 
> Answers to the TC Election questions are below. I'm happy to answer any
> other questions folks have too, in an open forum of course.
> 
> cheers,
> Zane.
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/043583.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046563.html
> 
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/045788.html
> 
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046934.html
> 
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/047025.html
> 
> 
> TC Election Questions
> =====================
> 
> (from
> https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions)
> 
> 
> * How do you feel the technical community is doing in meeting the
> OpenStack Mission?
> 
> (The mission is here, by the way:
> https://wiki.openstack.org/wiki/Main_Page just in case you don't have it
> committed to memory.)
> 
> I think we all have a lot of work to do on several fronts: - "simple to
> implement" and "massively scalable" in particular. But I'm very
> optimistic that work will get done because we have built a healthy,
> thriving community to do it.
> 
> * How do you feel the technical committee is doing in meeting the
> technical committee mission?
> 
> (That one is here:
> https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee)
> 
> I think the TC is doing a good job at encouraging the OpenStack ideals,
> but I think the size of the project as a whole has overwhelmed its
> capacity to provide _active_ technical leadership. We need to build up
> that capability.
> 
> * How would you characterize the various facets of contributor motivation?
> 
> I wouldn't, but since you ask... OpenStack is not a hobbyist project. No
> major open source project is. The vast majority of contributors are able
> to contribute because it is benefiting their employer somehow - either
> because they have a problem to solve directly with OpenStack, or because
> they are selling something complementary to OpenStack. We need to make
> contributing as easy and pleasant as possible, so the first group will
> contribute at all and so the second group will contribute as much as
> possible in their long-term interests and not only in their short-term
> interests.
> 
> * There is no argument the OpenStack technical community has a
> substantial rate of growth. What are some of the consequences of this rate?
> 
> The biggest and most important consequence is that we have lots of
> talented contributors working hard on solving real problems that our
> users have, and doing it in the open, the OpenStack way. Another is that
> we've outgrown some of the centralised shared resource structures that
> made sense in a smaller project. We'll need to work on decentralising
> and building communication paths.
> 
> * How would you characterize the experience new contributors have
> currently?
> 
> I would have to guess frustrating. The process starts badly with a bunch
> of hoops to jump through culminating in the CLA. At least the first
> patch is greeted with a friendly, helpful "Welcome new contributor"
> message. From there we should keep in mind that the experience differs
> from project to project. The smaller ones are probably doing OK for the
> most part, but the larger ones are struggling to provide the timely
> feedback that new contributors need. In some cases that's exacerbated by
> overly-bureaucratic processes and review nitpicking (which could be
> summarised as a generally procedure-focused rather than results-focused
> outlook).
> 
> * How would you describe our current state of communication in the
> OpenStack community?
> 
> We communicate a lot, and in the open, which is great. The hard part is
> filtering the fire hose. As we decentralise even more, we'll need to
> mitigate that problem by establishing fixed (rather than ad hoc)
> channels of communication, so that people hear about the things they
> need to without getting swamped. The Oslo liaison program is one great
> example of how to achieve this.
> 
> * The technical committee interacts with the foundation board on several
> different fronts. How would you describe these interactions?
> 
> Getting the TC and the Board on the same page on any issue is a big
> challenge, because the combined group is *huge* (~30 people). Discussion
> inevitably moves slowly at that scale, and the Board doesn't tend to
> hold wide-ranging open discussions between meetings the way the TC does
> on openstack-dev. Cultivating relationships is important, but most of
> the work will continue to get done by joint subcommittees.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/3a7eb981/attachment.pgp>