[openstack-dev] TC candidacy
doug at doughellmann.com
Tue Oct 7 20:30:37 UTC 2014
I am announcing my candidacy for a position on the OpenStack Technical
I am currently employed by HP to work upstream on OpenStack. I started
contributing in 2012, not long after joining DreamHost. I am one of
the founding members of the Ceilometer project, and a core reviewer
for the requirements and unified command line interface projects. I am
also part of the team working on the Python 3 transition, and have
contributed to several of the infrastructure projects. Kilo will be my
third term serving as PTL for the Oslo project, and I have served on
the Technical Committee for the last year. In addition to my technical
contributions, I helped to found and still help to organize the
OpenStack meetup group in Atlanta, Georgia.
I've included the answers to the formally posed election questions
below, but please follow up here with any other questions you might
have for me.
The OpenStack community is the most exciting and welcoming group I
have interacted with in more than 20 years of contributing to open
source projects. I'm looking forward to continuing to being a part
of the community and serving the project.
Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
Commit history: https://review.openstack.org/#/q/owner:2472,n,z
* Topic: OpenStack Mission
* How do you feel the technical community is doing in meeting the
* OpenStack Mission?
I am amazed by what our community produces. We have some truly
exceptional development teams building great software. We regularly
add new components to the system, and our feature set is as diverse as
the community. Our work is not perfect, but as we continue to refine
it based on experience and input from users, we are continually
improving the way we work and what we produce.
However, there are recurring themes in the user feedback after every
release: We need to make OpenStack easier to operate, easier to use,
and easier to debug. We are starting to build cross-project teams to
work more directly on some of these areas, and it's important that we
give priority to that work and consider usability and scalability as
* Topic: Technical Committee Mission
* How do you feel the technical committee is doing in meeting the
* technical committee mission?
We're fulfilling most of the mission, but we can do better.
The Zaqar graduation discussion is a good example of an area where we
need to rethink how we bring new project teams into OpenStack. There
are several similar suggestions to drop our current incubation and
integration process completely, and that is one option. Another is to
set up the resources we would need to do an objective technical
evaluation for projects. I favor a combination of those two ideas,
evaluating projects on several criteria from the users' perspective,
but deciding the "official" status of a team based on community
We have also recognized that we need some way to handle cross-project
initiatives such as improving our logging to make debugging easier,
but we do not yet have a formal structure in place to accomplish those
goals. The way we set up working groups for those sorts of jobs is
going to depend on the outcome of the bigger governance discussion,
but I think they should be organized by the TC.
* Topic: Contributor Motivation
* How would you characterize the various facets of contributor
I don't know if we have numbers, but my impression is that most of our
contributions come from people employed at least in part to work on
OpenStack. Their commitment to the project as a whole, outside of
their area of specialty, varies for a lot of reasons. We want everyone
to have a strong commitment to the whole project, but that's not
always realistic, because it's not always up to the individual to
decide how much time or effort they can put into working on OpenStack,
or into a given area. That's perfectly normal and OK. We can, and do,
welcome contributions from all sorts of people for all sorts of
* 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?
Growing so quickly is forcing us to think about how we organize our
selves and make changes explicitly, and more rapidly, rather than
allowing for a slower evolution. We've had a lot of blog posts and
mailing list threads talking about ways to handle the growth through
governance model changes to the project. These are important decisions
for us to make as a community, and we need to weigh both sides of each
For example, we want to be more inclusive and bring more project teams
into OpenStack, but doing that further strains our cross-project
teams' capacity to help us all with documentation, infrastructure, and
release management. More creative independence for projects can
increase complexity for deployers and users as we drift away from
consistent patterns. Providing incentives for creating new projects
may take away incentives for collaborating on existing projects,
ultimately hurting both projects. In each of these cases we want some
aspects of both sides of the equation, but we need to strike a
Working out the changes we need to our existing set of policies will
take more thought and discussion , as we try to predict the
consequences of the proposed changes and craft new policies that are
flexible enough to continue to maintain a healthy community.
* Topic: New Contributor Experience
* How would you characterize the experience new contributors have
There's no question that OpenStack has a steep learning curve, both as
a user and a contributor.
Documentation is useful as a reference, but there's nothing quite like
having an experienced guide helping you first hand. I had the benefit
of a couple of informal mentors when I started contributing. They
walked me through the long process of setting up the tools and
development environment I needed until I was able to submit my first
patch, helped me get the most out of the design summit, and generally
eased my entrance into the community. Today we have a few formal
programs in the community to match mentors and new community
members. Those programs deserve our support, but day to day, we can
all do a little bit to help each other out by answering questions and
sharing our knowledge freely.
* Topic: Communication
* How would you describe our current state of communication in the
* OpenStack community?
Our growth is making communication more challenging, but we are
The specs process has helped with technical planning, setting
expectations, and recording decisions. Still, we have a lot of
initiatives not tied directly to specs -- especially those that span
project boundaries and releases.
I told the Oslo team that my mantra for this cycle is "Write it down,"
by which I mean we should clearly document our discussions and
decisions so when a topic comes up again we do not have to rely on our
memory. IRC is a great medium for quick iteration, but it's lousy as a
Communication is the key to maintaining a healthy open source
community. Keeping up can be difficult, but we all have to pay
attention to the messages coming out of other teams, to watch for
anything relevant, then participate in the conversation.
* Topic: Relationship with the Foundation Board
* The technical committee interacts with the foundation board on several
* different fronts. How would you describe these interactions?
I have a somewhat better impression of the relationship between the TC
and Board than has been expressed by other candidates. We are
different groups, with different perspectives, but we are all working
in what we consider to be the best interests of the OpenStack project
and that means working together. The face-to-face meeting in Atlanta
allowed some of that attitude to show through in ways that it doesn't
always in IRC or phone meetings. We have had spirited debates on
topics like DefCore and the CLA, as is natural for groups with such
different perspectives, but we are also continuing to work together to
find ways to solve those and other issues.
More information about the OpenStack-dev