Merge pull request #1062 from justinsb/vote_for_justinsb

Automatic merge from submit-queue

Election guide: add justinsb
This commit is contained in:
Kubernetes Submit Queue 2017-09-14 08:01:27 -07:00 committed by GitHub
commit c7b4e06798
2 changed files with 71 additions and 1 deletions

View File

@ -50,7 +50,7 @@ Doug Davis | IBM | [@duglin](https://github.com/duglin)
Ihor Dvoretskyi | *TBA* | [@idvoretskyi](https://github.com/idvoretskyi) Ihor Dvoretskyi | *TBA* | [@idvoretskyi](https://github.com/idvoretskyi)
[Ilya Dmitrichenko](errordeveloper_bio.md) | Weave | [@errordeveloper](https://github.com/errordeveloper) [Ilya Dmitrichenko](errordeveloper_bio.md) | Weave | [@errordeveloper](https://github.com/errordeveloper)
[Jaice Singer DuMars](jaicesingerdumars_bio.md) | Microsoft | [@jdumars](https://github.com/jdumars) [Jaice Singer DuMars](jaicesingerdumars_bio.md) | Microsoft | [@jdumars](https://github.com/jdumars)
Justin Santa Barbara | FathomDB | [@justinsb](https://github.com/justinsb) [Justin Santa Barbara](vote_for_justinsb.md) | Independent | [@justinsb](https://github.com/justinsb)
Kris Nova | Microsoft | [@kris-nova](https://github.com/kris-nova) Kris Nova | Microsoft | [@kris-nova](https://github.com/kris-nova)
[Matt Farina](mattfarina_bio.md) | Samsung SDS | [@mattfarina](https://github.com/mattfarina) [Matt Farina](mattfarina_bio.md) | Samsung SDS | [@mattfarina](https://github.com/mattfarina)
Michael Rubin | Google | [@matchstick](https://github.com/matchstick) Michael Rubin | Google | [@matchstick](https://github.com/matchstick)

View File

@ -0,0 +1,70 @@
## Vote for justinsb!
## A little about me:
I have been involved with Kubernetes since before 1.0, primarily on AWS support
(I am a lead of sig-aws), but also contributed the original multi-zone &
NodePort support. I also started the kops project, to produce an open-source
and consistent Kubernetes installation tool. I'm an independent, working with
Kubernetes in my day job but not employed to contribute to it, so I contribute
instead where I see a problem or an unmet need.
## Here's why I am asking for your vote:
The steering committee's most important role is to make decisions where the
normal process has failed to reach consensus, which we expect to happen when
reasonable Kubernetes people disagree. I believe in this event our goal should
be to make decisions quickly and consistently. We should explain our reasoning
clearly both to persuade (or console!) the people who held the other view, but
also to try to establish precedent, such that we can avoid future
disagreements. If we are trusted to make decisions, we should above all else
strive to be predictable.
As an independent I will do so wearing my own two hats: that of a developer on
the project contributing because it is a positive personal experience, and that
of an end-user of Kubernetes valuing a stable and straightforward product.
## My manifesto:
* Where the steering committee is called upon to reach decisions, make them
quickly and consistently, with clearly articulated reasoning. We should aim to
establish and document the Tao of Kubernetes, where we have found disagreement.
* Value diversity amongst our contributor base and consider the happiness and
productivity of contributors and our end-users as our ultimate goals; more so
than the desires of our biggest sponsors, however welcome and well-intended
those desires may be.
* Our releases should be more focused on the end-user experience. We need to
better empower the release-team to reject changes that destabilize a release,
or that unnecessarily burden the end-user. We should identify and champion key
themes in each release that give each release a clear reason. This need not be
combative or negative, but should be done in a collaborative way by involving
the release team earlier in each release.
* We must continue to delegate responsibilities to the SIGs, but we must remain
mindful that the goal is the success of the Kubernetes project, not of the
individual SIGs.
* We should re-examine our processes, to ensure that the cost is worthwhile.
Where we have process whose burden outweighs the benefits, we should consider
alternatives.
* We should allow our many Kubernetes projects the freedom to experiment with
alternative processes, so that we reap the maximum benefits from being in
separate repositories and separately managed. We should then encourage broader
adoption of the approaches that have proved most successful.
Given the makeup of the electorate, I realize that this is not the most
populist manifesto. But I have watched other projects fall into exactly these
traps, and we need to ensure that our momentum does not pull us in different
directions, but continues to translate into progress. So I appeal to you as
individual contributors, or as custodians of an area of the project: a focus on
our greater goal will yield a successful project that we are all happy, proud
and honored to be part of, with more than enough responsibilities and
opportunities to go around! Where I personally have experienced
dissatisfaction with the project it has usually been due to a lack of
decision-making, and I believe an effective steering committee will unblock the
debates that otherwise are the biggest sinks of our time and energy. I ask for
your vote, to act as a member of a steering committee following those values.