Update justinsb bio for word limit

1 files changed, 22 insertions, 49 deletions

diff --git a/community/elections/2017/vote_for_justinsb.md b/community/elections/2017/vote_for_justinsb.md
index ea1a1f2c..bae8ece2 100644
--- a/community/elections/2017/vote_for_justinsb.md
+++ b/community/elections/2017/vote_for_justinsb.md
@@ -1,6 +1,12 @@
 ## Vote for justinsb!
 
-## A little about me:
+You can see my full "manifesto" [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ); we've been asked to provide a shorter summary here.
+
+This election is critical.  The steering committee is not an honorary position;
+it has effectively unlimited powers.  Serving is a duty, not a privilege, and I
+humbly ask for your vote.
+
+---
 
 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 &
@@ -9,62 +15,29 @@ 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
+If elected, I will serve 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:
+I believe I bring particularly strong experience on non-GCE, non-Redhat
+platforms, and on the realities of maintaining projects outside the core repo.
+I think these are likely to be some of the most challenging areas for the
+steering committee.
 
-* 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.
+## My manifesto:
 
-* 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.
+(Abbreviated from [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ) )
+ 
+* Reach decisions quickly & consistently; communicate them clearly.
 
-* 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.
+* Value a clear and efficient developer process.
 
-* 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.
+* Empower the release team with the goal of producing a more stable release.
 
-* 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.
+* Figure out how to delegate to SIGs without creating fiefdoms.
 
-* 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.
+* Streamline our processes.
 
-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.
+* Promote experimentation with alternative processes amongst our many projects,
+balancing against the need for a consistent experience, allow the best approaches to "bubble-up".