Hello, everyone!
I would like to run for re-election on the Technical Committee. I have
been an elected member of the TC since it was created in the Fall of
2012 [1]. I have been contributing to OpenStack since late 2011 (commits
[2] reviews [3]). My most substantial contributions have been to Nova,
where I also served as the PTL for the Havana and Icehouse releases. For
further details on my background, see openhub [4] or linkedin [5].
I have been a proactive member of the TC. I take my broad experience
with the project and work to turn it into change that puts us in a
better position for the future. Some specific examples of actions I’ve
taken may help demonstrate this.
Over the last cycle it became clear that the TC could do a better job at
communicating what we’re up to to the broader community. I helped
launch an ongoing effort to blog about TC activities. I wrote the first
[9] and third [10] posts of this series. We now intend to rotate the
authorship of these posts through a group of willing TC members.
I’ve become deeply familiar with the history of Neutron vs. nova-network
through my work with the Nova project. During my second term as the
Nova PTL, we unfortunately reached a point where we had to unfreeze
development on nova-network [11]. I wanted to find ways to help improve
the current situation and help prevent it from happening again. I
identified policy that could be added (must have explicit deprecation
and migration plan in place before graduation) [12] for the future. To
help with the current situation, I proposed that we kick off a round of
project reviews where we review all existing projects against our
incubation and graduation requirements [13]. This process resulted in a
gap analysis and plans for filling those gaps for Neutron [14], Trove,
Ceilometer, Horizon, Glance, and Heat. We are now much closer to being
able to deprecate nova-network than we were 6 months ago thanks to some
very hard work by the Neutron team. I think these reviews were very
productive and I hope to help continue this process with the TC going
forward.
The TC has the critical role to evolve and scale our structure and
processes to ensure the ongoing health of our development community.
We’ve worked through important changes in every cycle so far. From
recent discussions it is quite clear that it is time for another round
of big changes to how we organize our teams and projects. The TC itself
has even become a bottleneck in some cases. I see resolving these
issues as a top priority for the TC over the next release cycle.
There are far too many things wrapped up in the incubation and
integration statuses. They communicate different things to different
audiences. This overload has led to a lot of conflict. It’s a high
priority for me to ensure that with whatever changes we make, we value
an inclusive community that lets projects doing good work be a part of
OpenStack. We need to rework the organization such that what we’re
communicating is the most useful information for each audience. At the
same time, we need allow this growth in such a way that it doesn’t
provide unbearable strain on horizontal project resources like
documentation, infrastructure, or release management. The incubated and
integrated statuses are not doing the job, but I’m confident that we can
work through our next evolution, and I would like to be a part of
ensuring that happens.
Thank you all for your consideration. It’s an honor and a pleasure to
work with you. If there’s anything you would like to discuss, please
feel free to reach out to me.
Below you will find my answers to the provided questions [6].
*** Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the
OpenStack Mission?
To recap, the mission statement is “to produce the ubiquitous Open
Source Cloud Computing platform that will meet the needs of public and
private clouds regardless of size, by being simple to implement and
massively scalable.”
“ubiquitous” - I think the part we’re doing great here. OpenStack is
growing like crazy and is being used all over the place. The list of
supporting companies [7] is impressive. The number and diversity of our
contributors is even more impressive. With that said, we shouldn’t get
comfortable. There is a lot more to go.
“public and private clouds” - I think we do a nice job working to
support both of these use cases.
“regardless of size”, “massively scalable” - This one probably depends
on who you ask. :-) Our scalability depends on the project. In some
areas we’re doing great. In all areas, we have more improvements to
make. I think our biggest failure here has been how well we communicate
what to expect to the rest of the community. Some people expect that
they can take every component of the integrated release to large public
cloud scale. That isn’t true and we’ve done a poor job of setting
expectations here. This is something I’d like to improve on.
“simple to implement” - I think OpenStack is far from simple. It’s also
a large scale distributed system that is very incredibly flexible so it
can support a large number of different use cases. So, we should set
expectations accordingly. However, I still think there is a ton of room
for usability improvements.
*** Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the
technical committee mission?
The TC mission statement can be found in the governance repository [8].
The current version is: “The Technical Committee ("TC") is tasked with
providing the technical leadership for OpenStack as a whole (all
official programs, as defined below). It enforces OpenStack ideals
(Openness, Transparency, Commonality, Integration, Quality...), decides
on issues affecting multiple programs, forms an ultimate appeals board
for technical decisions, and generally has oversight over all the
OpenStack project.”
The TC is only two years old. If you look through our history, I think
the TC has done a nice job evolving processes and structure as OpenStack
has grown. The next evolution of process and structure has been the
most dominant area of discussion lately. I am very optimistic that we
can resolve those issues.
The ways that we could improve our technical leadership have received a
bit less discussion. As OpenStack grows into more and more projects, I
feel that leadership around standardization becomes more and more
important. I’d like to see the TC bootstrap an effort around APIs to
help improve our consistency and overall quality. We are also
discussing having a cross-project specs repository. It makes sense for
the TC to own this to help provide more structure to development efforts
that affect many projects.
*** Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?
People want to do work that matters and enjoy doing it. OpenStack is
clearly a project making a huge impact. We also need to make sure it’s
a pleasant community to participate in. There are a lot of things that
make some communities more enjoyable than others. There are obvious
things we want to avoid that are covered by the community code of
conduct [15]. I think feeling non-productive hurts motivation. We need
to keep working to identify and resolve issues that get in the way of
getting work done.
*** Topic: Rate of Growth
There is no argument the OpenStack technical community has a substantial
rate of growth. What are some of the consequences of this rate?
Just like any organization with growth, we have growing pains. I’d say
identifying and working on these growing pains has always been a core
part of what the TC does. I expect that to continue to be the case.
The coming cycle appears to be no different.
*** Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?
I suspect being a new contributor would be quite overwhelming. Joining
a project of this size and activity level is daunting for several
reasons. I welcome and applaud all efforts to help onboard new
contributors.
*** Topic: Communication
How would you describe our current state of communication in the
OpenStack community?
The way we communicate seems pretty typical for most open source
communities. We have a heavy emphasis on mailing lists and IRC. We
have a significant amount of in person meetups as well. For those that
are able to make it, I think they help. We just need to continue to be
sensitive to community members that can’t attend all events. Good
documentation of discussions and allowing discussions to continue on the
mailing list are important. This is largely done well already, but it’s
important that we continue to emphasize it.
*** Topic: Relationship with the Foundation Board
The technical committee interacts with the foundation board on several
different fronts. How would you describe these interactions?
Our interaction has been improving. We’ve started holding joint
meetings at the OpenStack summit. There has also been quite a bit of
interaction on the DefCore topic specifically throughout the development
cycle. I look forward to continuing to collaborate with the board on
the topics where it makes sense.
[1] http://ttx.re/history-of-openstack-governance.html
[2]
http://stackalytics.com/?user_id=russellb&release=all&project_type=all&metric=commits
[3]
http://stackalytics.com/?user_id=russellb&release=all&project_type=all&metric=marks
[4] https://www.openhub.net/accounts/russellb
[5] https://www.linkedin.com/in/russellbryant
[6]
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions
[7] http://www.openstack.org/foundation/companies/
[8]
http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst
[9]
http://www.openstack.org/blog/2014/06/openstack-technical-committee-update/
[10]
http://www.openstack.org/blog/2014/07/openstack-technical-committee-update-july-1/
[11]
http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html
[12] https://review.openstack.org/#/c/70389/
[13]
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026450.html
[14]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
[15] http://www.openstack.org/legal/community-code-of-conduct/
--
Russell Bryant
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
