confirmed
On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby <ma...@redhat.com> wrote: > My name is Maru Newby, and I am announcing my candidacy for the > Technical Committee (TC) election. > > tl;dr; > > I'm a relative unknown outside of Neutron, but I've been helping to drive > high-level change in that project. I would welcome the opportunity to bring my > energy and dedication to OpenStack-wide concerns as a member of our TC. > > If you're willing to read any part of this email, I hope it would be 'Why vote > for me?'. > > If not, and you are as frustrated with the status quo as I am, I hope you will > consider voting for candidates that support the goal of building a more > engaged > TC focused on ensuring that participation in OpenStack becomes more enjoyable > and sustainable. > > Thank you for reading, and make sure to vote! > > > * Why vote for me? > > If elected, I'm going to be a squeaky wheel advocating for anything and > everything that empowers our development community to deliver useful software > into the hands of users. If this puts me at odds with those that want to > focus > on issues like 'What is OpenStack' or 'How can we systematize project culture > to > make it easier to communicate?', good! I believe that you, as a technical > contributor to OpenStack, need stronger representation of your viewpoints on > our > TC, and I'm one of the strongest advocates you're likely to find in this > community. I am currently employed full time upstream, and I am willing and > able to devote the resources necessary to do justice to the role. > > I also intend to advocate for focusing the OpenStack community on ambitious, > but > achievable, goals. I believe this will require making hard choices about > which > use cases we can reasonably expect to support. To me, the idea that OpenStack > can be all things to all people is dangerous. It's just as likely that in > trying to do it all, we do little of it well, and risk irrelevance. I think > our > primary competition is and will continue to be proprietary cloud, and my > biggest > fear is that we become unable to compete on cost due to the operational > complexity required to make everyone happy. We need to keep our collective > eyes > on the ball! > > To be clear, I want to be a part of a TC with as diverse a group of viewpoints > as possible to ensure that we have to work hard to achieve consensus. If > agreement is reached too easily, there is probably something wrong. My > wanting > to push a developer-centric agenda doesn't mean that I don't respect the need > to > address other issues. My voice would be one of many, and I recognize that > consensus requires compromise. > > > * Why not vote for me? > > There are candidates more deserving of your vote if you think our TC shouldn't > have a role in providing leadership to the OpenStack community. If you > believe > that our TC is already sufficiently developer-focused, then I also don't > deserve > your vote. > > This is in no way to suggest that I want to see our TC become a top-down > decision-making body. This is still an open source project, after all, and I > know first-hand the complexities of the culture involved. I do think it > appropriate, though, for an elected body with as much visibility as our TC to > participate more actively in addressing the challenges we face. > > > * Key concerns > > There are any number of issues facing OpenStack today, but the items on the > shortlist that follows are the concerns that I would like to see the TC > champion in the near-term: > > ** Scaling our development effort > > The stated goal of our TC of late has been to 'get out of the way'. I > wholeheartedly support this intention, and would like to see it extended to > how > our TC approaches governance beyond project evaluation. I think our TC should > be responsible for proposing what we want to achieve rather than in how we > should achieve it. Outcomes, rather than process. I think project-level > contributors are best equipped to solve the problems of implementation. Our > TC > can take responsibility for setting OpenStack-wide expectations and in > facilitating - rather than managing - cross-project advancement towards these > goals. More than ever, we need to be pulling in the same direction, and I > think > our TC is an obvious candidate to rally ourselves around. > > I hope we all recognize that we can't scale OpenStack if decisions are > constantly gated on a small group of 'tastemakers'. Delegation of trust is > required, whether at the level of our TC or the individual projects. I think > we > need to take our TC's recent momentum to the project level and find ways to > increase delegation of responsibility. Nova and Neutron, for example, have > had > to face ever-increasing demands with the same small pool of core reviewers, > and > many of you know all-too-well the pain that has resulted. Core reviewers - > like > the pre-big tent TC - have inadvertently become micromanagers as their > responsibilities have evolved beyond their capacity to meet them. The model > of > direct trust - in which each core needs to trust every other core - doesn't > scale due to fundamental human limits. This is at odds with OpenStack's need > to > grow, and I want our TC to lead an effort to help affected projects find their > way out of this logjam. > > ** Growing our contributors > > Not only does the current core reviewer regime in some projects limit our > capacity to get work done, not only does it contribute to burnout and a > perception of indifference - it also has the effect of restricting growth > opportunities for new contributors. How can a contributor hope to stretch > themselves if they don't have the opportunity to take on additional > responsibility because the positions of authority are already occupied and > turnover is negligible? This problem has gone on long enough that I think it > is > time for our TC to support affected projects in finding solutions. We need to > provide contributors more and better avenues for growth if we hope to sustain > our development efforts over the long-term. > > Similarly, at the level of our TC, I want to see a governance change that > imposes term limits on elected positions. We need continuity of leadership, > but > not at the cost of limiting the growth opportunity for our future leaders. > Influence is extraordinarily sticky, as we've seen with incumbents almost > always > winning over challengers in any given OpenStack election, and we need to > balance > that stickiness with deliberate policy. > > ** Unwinding the integrated gate > > Over the past year I've seen awareness grow as to the costs of our integrated > gate. Those costs were worth bearing in the past, but times have changed. > Co-gating has allowed our biggest projects to come to rely on the implicit > behavior of their co-gating siblings rather than forcing all involved to rely > only on explicit API contracts. The resulting combinatorial increase of > interaction complexity has imposed a severe penalty on the velocity of > OpenStack > as a whole. I think the way forward is having our TC work with co-gated > projects to define a timeline for decoupling. Without an explicit mandate to > focus up-front resources on the increased testing rigor required to remove the > co-gating requirement, affected projects will continue to suffer from > unnecessary coupling and the resultant impact on quality, reduced merge > velocity, and contributor frustration. > > > * Who am I? > > I've saved this for last, since I think the issues are more important than > who I > am. If you've read this far, though, you probably want to get a better sense > of > who I am before you consider casting a vote in my favor. > > I've been developing software professionally for almost 20 years, and and I've > been using Python professionally for more than 14. I've been responsible for > enough legacy systems that I am extremely focused on maintainability. For me, > maintainable software is well-designed, well-written, and well-tested, and > only > constant iteration can hope to achieve these goals. But given that > maintainable > software is only valuable if it meets user needs, I've always focused on the > user first. This focus has taught me the value of listening and of being > humble > in the face of disagreement (too often the result of misunderstanding). > OpenStack has proven an ideal match for this background, and I enjoy applying > myself to the challenges we face. > > I've been an active upstream contributor to OpenStack since Essex (2012), a > core > reviewer in Neutron for most of that time, and for the past 2 years have been > privileged to work upstream on a full-time basis. I have been a capable (if > inconsistent) reviewer, but mainly I have made it my responsibility to improve > Neutron's testing story. Early efforts included advocating for unit testing, > kicking off the effort to write Tempest scenario tests for Neutron, and more > recently I've led the effort to enable in-tree functional and API testing. > The > latter effort required considerable coordination with both the QA and Infra > teams. In my experience, there is no amount of post-dev QA that can keep up > with a developer community that doesn't have primary responsibility for the > quality of what they merge. I've learnt the hard way that enabling pre-merge > testing is key to mandating a developer focus on the quality of what they are > implementing. Elected or no, I will continue to promote this vision of > test-focused development within OpenStack. > > I've also been involved in improving Neutron's culture and development > process. > I've worked closely with Kyle Mestery, the current Neutron PTL, and Mark > McClain, the previous PTL, in improving how the project is run. I've learned > the hard way that change requires detailed knowledge of the culture, a local > base of support, and a knack for diplomatic tact. I think our TC can do a > more > effective job in providing the vision and leadership that OpenStack as a whole > needs to take us to the next level. I believe the experience I have gained in > facilitating change in Neutron will prove valuable in getting us there. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
