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