confirmed. Note that we are making an exception here for a brand new parent. I'd like to remind further candidate to use the proper "TC candidacy" mail subject.
On 08/10/14 09:33 PM, Sean Dague wrote: > I'd like to announce throwing my hat into the ring for the OpenStack > Technical Committee. > > = My Background on the Project = > > I've been a contributor to OpenStack since late in the Essex release. I > was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer > on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project > Config repo in infra, and a host of other projects in OpenStack. I was > elected to the TC last fall as part of the first fully directed TC. > > You might also know me from the fact that I spend a lot of time on the > OpenStack gate, which really means I spend a lot of time trying to > understand why when all the OpenStack components run together, they > often break horribly, and actually try to debug and address those. I was > part of the team that built Elastic Recheck > (http://status.openstack.org/elastic-recheck/) for that effort. > > In any particular release of OpenStack I'm typically one of the largest > reviewers of code. A lot of these are help shepherding in easy fixes > that get lost in our review queues. I built things like Gerrit Dashboard > Creator (https://github.com/stackforge/gerrit-dash-creator) to make it > easier for reviewers to sift patches to make sure that good patches > don't get lost, and make reviewer's lives easier. > > And I am a strong believer that the way we grow our community is through > growing our contributors. This is one of the reasons I kicked off the > OpenStack Bootstrapping Hour > (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and > Dan Smith, to provide one avenue for this growth to happen. I think many > other are required as well, but this is one way to get us started. > > = My Views on the Future of OpenStack and the TC = > > I feel like OpenStack is at a crossroads. The original definition of the > integrated release, and horizontal teams was built around the concept of > 2 projects. It worked at 5. It was strained at 8. And I think we're now > on the very of it being completely broken. > > I think that in order for OpenStack to move forward we need to > pragmatically redefine the integrated release as the set of horizontal > components that have to be linked together to be useful. Exactly the > right unit I think is up for debate. It could be as small as Nova, > Glance, Keystone, Neutron. It might include Cinder, Designate, and / or > Oslo (I can see the case for and against any of these). Those should be > the projects that QA, Docs, and Stable Maint, Release Management, > Security Team, and the TC needs to take responsibility for. > > I think that we need to have an expansive ecosystem where projects like > Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally, > Ironic, and all the other really interesting projects can flourish. I > think their inclusion in the OpenStack umbrella should be a lightweight > process that is largely a self assessment and an acceptance of certain > principles that are core to OpenStack. I think these projects should be > self responsible for their own QA, Docs, Stable Maint, Security, and > Release Management. And I think mentoring should be made available to > help them with any of these. I believe a structure similar to the User > Committee is probably most appropriate here. However we get this body, > it should have an electorate (directly or indirectly) that represents > ATCs from the broadest expanse of our ecosystem. > > I think the TC needs to evolve from a policy body, to a body that's > primarily directly responsible for the integrated release (as I defined > above). Direct responsibility means more than approving and managing gap > analysis plans. It means diving directly into project code across all > the integrated release projects at substantial regularity. It could mean > the TC inheriting +2 on the integrated projects and horizontal efforts > supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we > could only do this with a strong set of expectations and checks and > balances to prevent abuse, but it's an idea that's interesting to think > about). > > I would like to think about this as a tight integrated release plus a > large and solid ecosystem. > > These are things I'm going to push for going forward, whether or not I'm > on the TC, however I think the idea of having the TC take more ownership > of the integrated release, directly. We need an OpenStack base box set > with more full and cohesive user experience (one that doesn't require > understanding and maintaining multiple db systems), that is deployable > at everything from small colleges and institutions, to giant places like > wall street, telcos, and research institutions. And then we need to have > space to promote great expansions to OpenStack the institutions can > deploy as needed for their needs that a much freer to use exciting new > technology to solve interesting problems. > > = Standard TC Questions = > > == How do you feel the technical community is doing in meeting the > OpenStack Mission? == > > Our mission statement is: "To produce the ubiquitous OpenSource Cloud > Computing platform that will meet the needs of public and private clouds > regardless of size, by being simple to implement and massively > scalable." (http://www.openstack.org/blog/2010/07/introducing-openstack/) > > I honestly feel like we're only doing an sort of OK job right now. I > think that the current growth of services and they way we implement them > (by bringing in a lot of new external dependencies) is not holding true > to "being simple to implement". I think that's excluding the use of > OpenStack at smaller institutions. If OpenStack is only in the toolchest > for large sophisticated institutions, it will not become ubiquitous. > > Linux was deployed in production first by small ISPs, entities with only > a few employees. If OpenStack can only be deployed by having a very > skill integrator come on board, it by definition can't be Ubiquitous. > > My feelings around a smaller nucleus/layer/ring/zone/integrated release > are largely shaped by my feeling that we're losing the smaller users of > OpenStack. And that's something we can fix. > > == How do you feel the technical committee is doing in meeting the > technical committee mission? == > > The mission: The Technical Committee ("TC") is tasked with providing the > technical leadership for OpenStack as a whole (all official programs, as > defined below). It enforces OpenStack ideals (Openness, Transparency, > Commonality, Integration, Quality...), decides on issues affecting > multiple programs, forms an ultimate appeals board for technical > decisions, and generally has oversight over all the OpenStack project. > (https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee) > > In the current TC, I'm one of the newest OpenStack community members. I > was honestly surprised with how much TC time was spent evaluating new > project requests (and this is growing over time). I think the TC mission > for providing technical leadership and even understanding issues > affecting multiple programs becomes very strained when the scope of that > governance includes the whole OpenStack ecosystem. And I think it will > limit the TC's effectiveness at having oversight when it is so far removed. > > == How would you characterize the various facets of contributor > motivation? == > > I'm not really sure the intent of this question, but I'll take a swing > at what the author might have intended. A very large amount of OpenStack > work today is sponsored. Some of it is very vendor oriented for very > specific features those vendors want in the OpenStack changelogs, some > of it is people that love this community, and have found entities that > will support that. The fact that a huge number of our community leaders > are not working at the same company as when they started with OpenStack > (including myself) speaks to that passion. > > I'd honestly like to see more small contributors, and more people > feeling like they could make an impact to OpenStack even if the don't > have the privilege to work on it full time. > > == There is no argument the OpenStack technical community has a > substantial rate of growth. What are some of the consequences of this > rate? == > > The rate of growth has very much meant that most contributors to > projects only contribute to their one effort. The cultures in each > project have grown quite different over time as to what's acceptable > patch culture for each project, acceptable review culture, how bugs get > handled, what's validated, and many more things. > > When I joined the projects one of the mantras for no non python > OpenStack projects was that common language and common tooling would > mean that developers and operators would have an easy time moving from > one project to another to address an issue. > > I think the explosive growth we've seen, and the challenges with > coherent integration of all these moving parts, has shown that there is > a lot more to unified experience than common language and tooling. > > I think it has also very concretely strained the Horizontal efforts past > their capacity points. Docs, QA, Stable Maint, Security, all very much > have to now pick their battles and leave a lot on the cutting room floor. > > Take this example: I recently started working on the final Nova fixes > for a cross project security issue that was made public 14 months ago - > https://bugs.launchpad.net/keystone/+bug/1188189. It's honestly unclear > if this has been completely addressed in other projects. > > == How would you characterize the experience new contributors have > currently? == > > Terribad. > > 24 steps of CLA madness, multiple ids, signing stuff, to get to the > point of submitting your first bug fix is insane. > > You have exactly one chance to make a first impression, and today I > think the process of contributing to OpenStack prior to even uploading > to Gerrit is onerous enough that we're preventing most of our best > future OpenStack contributors from ever existing. > > This needs to change. > > == How would you describe our current state of communication in the > OpenStack community? == > > I'm going to take "our" to mean all of us in the OpenStack community. > And the best way I can say is fragmented. We have the mailing list, but > with so many efforts being on list (Nova and Fuel being in the same > list, for instance) it means that many things get lost. We have a vast > array of per project IRC channels... though very little traffic on > #openstack-dev. As far as I can tell only a very few core developers > currently monitor #openstack-dev for interesting content, which adds > huge burden to any cross project effort that's not got a dedicated cross > project channel. > > == The technical committee interacts with the foundation board on > several different fronts. How would you describe these interactions? == > > Confused? No, I mean I'm confused, because honestly there seems to be > not that many fronts in which they interact. I was very mixed on DefCore > because it seemed like so much of the important work there happened in > face to face meetings in San Fran. And there kept being real confusion > over intent. > > Beyond that I feel like there hasn't been a ton of Board / TC > interaction. The joint Atlanta meetup was good, and I think some > concerns that got raised in the room did get talked about. But I feel > like there are actually quite different scopes of the Board trying to > define the commercial ecosystem and market dynamics, and the TC trying > to define a set of bits that do a thing. And hopefully keep doing that > thing even when some more bits are added. > Honestly, perhaps the disconnects that currently exist between the TC > and the Board are largely around the fact that the only place our roles > seem to overlap is near the trademark definition, and so vastly > different perspectives exist based on the day to day challenges each face. > > = Final thoughts - caveats = > > I'll pre-apologize for any oddities in this write up, or if I missed > context on questions that might have been surfaced on the mailing list. > Or if people have noticed me absent in any community threads in the past > week in which they expected to hear my voice (I have not read any email > related to the project since Oct 3rd). I'm currently functioning under a > bit of sleep deprevation after the arrival of our latest family member - > https://twitter.com/sdague/status/519173169643388929, and will be > disconnected from the community for the next couple weeks as I focus on > family. I only broke the sabbatical because TC candidacy had an > expiration date. > > Will be back roaring and raring to go by Paris. And will look forward to > seeing you all there whether or not you want me back on the TC for > another year. :) > > -Sean >
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