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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
