Open Stack

confirmed


On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby <marun at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2