101 lines
5.3 KiB
Plaintext
101 lines
5.3 KiB
Plaintext
Hi everyone,
|
|
|
|
I am announcing my candidacy for a position on the OpenStack Technical
|
|
Committee. For those who don't know me yet, I work for the OpenStack
|
|
Foundation, and I've been serving on the Technical Committee as its
|
|
chair since it was created. Beyond coordinating the TC activities, upstream
|
|
my focus is mainly on Release Management.
|
|
|
|
I'd like to use my candidacy email to explain the role of the Technical
|
|
Committee, what we did over the past year and what would be my focus if
|
|
you'd have me for one more year. The Technical Committee fills a number
|
|
of tasks:
|
|
|
|
1. Serving its constituency
|
|
|
|
The Technical Committee handles communications and interactions with other
|
|
parts of OpenStack community and governance, like the Board of Directors or
|
|
the User Committee. It also acts as a governance safety valve, providing a
|
|
final decision-making mechanism for upstream development. Finally, it is
|
|
responsible for ensuring we have an inclusive and welcoming environment for
|
|
open collaboration.
|
|
|
|
I think we made great improvements over the last year in this area. The
|
|
relationships with the Board and User Committee improved a lot, and we are
|
|
collaborating on strategic improvements for OpenStack in common workgroups
|
|
now. Also the TC was not used that much over the last year to make final
|
|
calls or resolve disputes, which is a good thing and shows that our governance
|
|
model works. We have a number of challenges ahead in terms of inclusivity, in
|
|
particular to better support part-time contributors and Asian contributors,
|
|
where timezones, language and cultural difference might get in the way. If
|
|
elected, I intend to work to evolve how we operate to be more welcoming of
|
|
those groups.
|
|
|
|
2. Defining which teams are part of OpenStack and which are not
|
|
|
|
Another big part of what the Technical Committee does is to define the list
|
|
of "official" project teams whose deliverables are considered a component of
|
|
"OpenStack". That means evaluating new team applications as they come, but
|
|
also refining the limit between "in" and "out" of OpenStack official projects.
|
|
That includes interesting discussions about how far up the stack we should go,
|
|
but also more difficult discussions about removing dead efforts or cutting
|
|
down areas that hurt us strategically. We also constantly need to balance
|
|
our community's integrity/principles with reality: in terms of supporting
|
|
new programming languages like Golang, but also in terms of open collaboration
|
|
(should driver teams be considered as official or 3rd-party teams ?).
|
|
|
|
Over the last year we managed to tackle a large number of those questions.
|
|
We refined the process for adding programming languages, finally opening the
|
|
door for Golang projects in OpenStack. We more aggressively removed projects,
|
|
and just started the discussion on our first "strategic" removal (the Community
|
|
App Catalog). Significant change takes time, so most of those discussions are
|
|
still in progress. If elected, I look forward to completing those discussions,
|
|
and together with the Board and User Committee produce maps of the OpenStack
|
|
universe that will make it clearer what OpenStack is (an open infrastructure
|
|
framework that you can deploy in various ways) and what it is not.
|
|
|
|
3. Considering OpenStack as "one platform" and influencing its direction
|
|
|
|
An increasingly important task of the Technical Committee is to take a step
|
|
back and look at OpenStack as a whole. While it is made up of several
|
|
components, OpenStack is "one platform" for open infrastructure. We should
|
|
make sure that OpenStack components are easy to operate together, and behave
|
|
in a consistent way as much as possible. We should /also/ make sure that it
|
|
is easy to plug other infrastructure solutions on an OpenStack base, or to
|
|
integrate OpenStack components in other software stacks where they make sense.
|
|
|
|
Over the past year we introduced "release goals" as a means to make progress
|
|
in the same direction together, and as a means to reach base levels of
|
|
functionality and consistency across the stack. I personally participated in
|
|
the Architecture workgroup, and pushed the idea of "base services" (which all
|
|
components can assume will always be present in an "OpenStack" installation,
|
|
and therefore can depend on them being present). This should hopefully help us
|
|
reach the next step in terms of scaling and performance, by adopting mature
|
|
external solutions rather than forcing us to reinvent the wheel locally. If
|
|
I'm elected, I intend to pursue those initiatives.
|
|
|
|
4. Documenting existing culture and systems
|
|
|
|
The final task of the Technical Committee is to produce clear documentation
|
|
about what we mean by "the OpenStack Way" or "being one of us". There is a lot
|
|
of unwritten shared understandings in OpenStack, but without anyone to write
|
|
it down, it's hard for new members of our community to absorb that culture and
|
|
internalize it.
|
|
|
|
This was a major focus for the Technical Committee over the past year.
|
|
In particular we documented the "OpenStack principles", and started creating
|
|
a clear vision for the next two years of the Technical Committee. If elected,
|
|
I intend to continue working on that vision to further explain and clarify
|
|
the direction we are going to.
|
|
|
|
|
|
Thanks for reading so far. I hope this candidacy email clarifies a bit what
|
|
the role of the Technical Committee is, what the current membership achieved
|
|
over the past year, and what would be my focus, if elected, for the coming
|
|
year.
|
|
|
|
Thank you for your consideration!
|
|
|
|
--
|
|
Thierry Carrez
|