<div dir="ltr"><div class="gmail_default" style="font-size:small">Zane,</div><div class="gmail_default" style="font-size:small">I was lucky enough to join the OpenStack community when you're doing all of the things listed above. You've done an amazing job. Thank you.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 28, 2020 at 6:42 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As promised last year, I will not be running for a third term as a <br>
member of the Technical Committee. I'm stepping down to spend more time <br>
with my family (no, really! ;)<br>
<br>
I thought this would be a good opportunity to talk to those folks who <br>
are thinking of running for a seat, or who aren't but should be. The <br>
most common question I hear from potential candidates is "what should I <br>
actually do on the TC?" I can't tell you what *you* should do, but I can <br>
tell you what I did and how that worked out. Maybe that will give you <br>
the flavour. And perhaps (he hinted) some of the other outgoing TC <br>
members can do the same to provide more of a cross-section.<br>
<br>
* I drafted and edited the review guide, "How to Review Changes the <br>
OpenStack Way", to try to ensure that the best parts of our review <br>
culture are evenly distributed across the project: <br>
<a href="https://docs.openstack.org/project-team-guide/review-the-openstack-way.html" rel="noreferrer" target="_blank">https://docs.openstack.org/project-team-guide/review-the-openstack-way.html</a> <br>
(This started as part of an initiative from Julia Kreger to reduce <br>
nitpicking in reviews.)<br>
<br>
In theory anybody could have done this, but in practice I think this is <br>
one of those things that only somebody elected to the TC could have <br>
driven. I received a lot of feedback afterwards (which is unusual for <br>
anything the TC does): several people, and one whole team, mentioned <br>
that they had tweaked their reviewing style after this discussion. And <br>
hearing their feedback prompted me to tweak my own reviewing style as well.<br>
<br>
* I drafted and edited the Vision for OpenStack Clouds: <br>
<a href="https://governance.openstack.org/tc/reference/technical-vision.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/technical-vision.html</a>. <br>
This was a ton of work as it involved consulting with so many people: <br>
first, folks in the community who on the surface appeared to have quite <br>
different visions for what OpenStack should be, who later turned out to <br>
not be so far apart as we all thought. After a lengthy round of reviews, <br>
I approached every project team individually to explain the specific <br>
relevance to them, and seek their feedback. Finally, I presented it to <br>
the OSF Board and held an in-person feedback session at the Forum, after <br>
all of which it was approved by the TC.<br>
<br>
I have some mixed feelings about the success of this. I still believe it <br>
was desperately needed... in about 2013. Now the Kubernetes community is <br>
succeeding at engaging with actual end users (not just operators), which <br>
OpenStack has always failed to do. With contributions to OpenStack <br>
dropping, it's not clear that we can, or necessarily should, sustain <br>
such a broad vision. It is my hope that if and when the community needs <br>
to discuss adjusting our scope, we will do so by amending this document <br>
- going through it section by section and deciding which parts to double <br>
down on and which to allow to fall by the wayside - and not by a series <br>
of ad-hoc actions that leave everybody confused as to what the project <br>
is supposed to be once again. On a personal level, the vision has been <br>
extremely valuable for me because it required me to spend a lot of time <br>
thinking deeply about the various components of OpenStack and how they <br>
fit into a greater purpose. A large portion of the value comes from <br>
participating in the process, not necessarily the final document. I hope <br>
that all of the folks who helped along the way got as much out of it as <br>
I did.<br>
<br>
* I developed the process by which we keep OpenStack up to date with new <br>
releases of Python: <br>
<a href="https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html</a><br>
<br>
I also shepherded it through the first couple of release cycles, to try <br>
to entrench it as a standard part of each release. (BTW this task needs <br>
somebody to take it over.) This mostly involved pointing people back to <br>
the resolution and inviting them to formally update it every time <br>
someone tried to bikeshed the details, which happened more than I ever <br>
believed possible. (To date there have been no changes proposed to the <br>
resolution.)<br>
<br>
* I engaged with the OSF Board to pass on feedback from members in the <br>
developer community on the process for adding new Open Infrastructure <br>
projects (e.g. Zuul, StarlingX, Airship, Kata). Sometimes the work of <br>
the TC is completely invisible! I also tried to convey information the <br>
other way, publicising information that was otherwise only available by <br>
attending board meetings. (Most TC members usually attend board <br>
meetings, including the in-person joint leadership meetings held before <br>
Summits.)<br>
<br>
* In response to feedback from the board, I replaced the "Help Most <br>
Wanted" list with the "Upstream Investment Opportunities" list, and <br>
kick-started the rewriting of the existing entries in a format that is <br>
more targeted at decision-makers: <br>
<a href="https://governance.openstack.org/tc/reference/upstream-investment-opportunities/index.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/upstream-investment-opportunities/index.html</a> <br>
(Huge thanks to Tom Barron, who did even more work to complete the job <br>
of converting all of the existing entries - proof that you don't need to <br>
be a TC member to start contributing to governance activities.)<br>
<br>
It remains to be seen whether this will have any effect, but this <br>
content is now being shared in the community newsletter, and the board <br>
is making moves to use it to actively solicit contributions to the <br>
community. Previously they felt unable to make use of the Help Most <br>
Wanted list because it was written with the wrong audience in mind.<br>
<br>
* I tweaked the guidelines for the release naming system to better align <br>
with our actual practice, because they had diverged somewhat. Believe it <br>
or not, this one issue took up more of the TC's time than any other <br>
thing that happened in 2019, and I'm very glad that we ended up not <br>
needing these tweaks because we eventually replaced the process <br>
wholesale, with one that makes it explicit that the TC is ultimately <br>
accountable for the release name not causing any international incidents <br>
or other snafus.<br>
<br>
* I researched and documented a design, developed during extensive <br>
discussions with many members of the technical community, for a new kind <br>
of simplified cloud built partially using OpenStack components but <br>
designed to be Kubernetes-native first: Project Teapot <br>
<a href="https://governance.openstack.org/ideas/ideas/teapot/index.html" rel="noreferrer" target="_blank">https://governance.openstack.org/ideas/ideas/teapot/index.html</a><br>
<br>
I do think this is worth building, but if nothing else I really hope <br>
this helps bring into focus the parts of OpenStack that remain essential <br>
in a Kubernetes-centric world. In writing this I was very much guided by <br>
the Vision for OpenStack Clouds as well as the ways in which Kubernetes <br>
expects to interact with an underlying cloud. I think we need more of <br>
these kinds of exercises, and while they don't have to be sponsored by <br>
TC members, I think it helps.<br>
<br>
<br>
If there's a pattern here it's this: take something that's implicitly <br>
agreed upon by the community (whether we realise it or not), write it <br>
down, seek feedback, and make it explicit so that anyone can refer to <br>
it, rather than leaving it as closely held tribal knowledge.<br>
<br>
Of course it goes without saying that I was involved in many more <br>
discussions and reviews that were led by others. I'll leave it to them <br>
to talk about those. And it should also go without saying that all of <br>
the work listed above was greatly improved by the input of the many <br>
talented folks in our community who contributed.<br>
<br>
<br>
In my humble opinion OpenStack is the best open source community of its <br>
size ever created. That's because we believe not just in one 'open' <br>
(source), but four <br>
(<a href="https://governance.openstack.org/tc/reference/opens.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/opens.html</a>); because <br>
we're committed to using open tools to build open software; and because, <br>
while it's certainly not the case that we can't improve, we have managed <br>
to do this while avoiding a widespread culture of bullying. To do all of <br>
this on the scale of OpenStack was, as far as I know, completely without <br>
precedent. (Perhaps the ASF comes closest, but its projects operate <br>
independently, unlike OpenStack subprojects.) All of us should be proud <br>
of this achievement. But it didn't happen by accident: it is the product <br>
of concerted effort by leaders in our community over the course of a <br>
decade. It's been a tremendous privilege to work alongside some of those <br>
folks, both before, during and (hopefully) after my time on the TC. I <br>
have learned so much from them. Now it is time for others to step up and <br>
continue to build that legacy, as the project evolves and adapts over <br>
time. The diversification of the OSF also gives us the opportunity to <br>
spread our ethos to other projects under the same umbrella, and from <br>
there to the open source community as a whole.<br>
<br>
However, we must remember that having a great community is not enough. <br>
To remain relevant, we also need to produce software that meets users' <br>
needs, which change over time. By an accident of fate I have approached <br>
OpenStack from a different direction than most - I came to OpenStack via <br>
the Heat project, which means I've always looked at it from an <br>
outside-in standpoint: users are building cloud applications, how can <br>
OpenStack provide them with what they need from a cloud through an open <br>
API? Many others, by necessity, have approached it from the inside-out: <br>
we have all this hardware, how can we expose its capabilities to users? <br>
I think it is fair to say that many of these folks and I have found each <br>
other's views to be mutually incomprehensible over the years. In writing <br>
up the Teapot design, I have learned a lot more about the other <br>
perspective. I believe we will need a more people to also grow their <br>
understanding in the opposite direction to avoid the trap of most <br>
capital-E "Enterprise" software - designed to check the boxes of those <br>
who decide what products to buy, but widely hated by all those forced to <br>
actually use it. Future TCs will have to grapple with this because <br>
nobody else in the community is really empowered to do so. The <br>
openstack/ideas repo that JP created is a great place for anybody to <br>
start documenting ways that we can improve.<br>
<br>
For my part, this is not goodbye. However, I have already been splitting <br>
my time between OpenStack and <a href="http://metal3.io" rel="noreferrer" target="_blank">metal3.io</a> and I expect that the drift in <br>
the other direction will only accelerate now that I no longer have any <br>
formal responsibilities here. Please feel free to contact me or ask <br>
questions if you think I can help.<br>
<br>
Stay safe out there, and by "out there" I mean physically isolated in <br>
your own homes for the next little while.<br>
<br>
cheers,<br>
Zane.<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b style="font-size:small;color:rgb(51,51,51)">Trinh Nguyen</b><br></div><div><u style="font-size:12.8px;color:rgb(0,0,0)"><a href="https://www.edlab.xyz" target="_blank">www.edlab.xyz</a></u><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>