On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby <> 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:

Elizabeth Krumbach Joseph || Lyz || pleia2

OpenStack Development Mailing List (not for usage questions)

Reply via email to