[openstack-dev] [all] Question for the TC candidates

Maru Newby marun at redhat.com
Fri Apr 24 21:41:39 UTC 2015


> On Apr 23, 2015, at 9:14 AM, Chris Dent <chdent at redhat.com> wrote:
> 
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?
> 

I have strong opinions about how we can improve quality.  I stated some of them
in my candidate email.  I think we have a more pressing concern, though. How do
we ensure that our TC is capable of effecting the change we require?

Our TC's primary mission used to be defining what OpenStack was and was not.
The move to a 'big tent' model reduced the need to focus on that issue, and now
our TC needs to direct its attention to improving our community and the software
it delivers.  This new mission changes the game, because top-down direction is
not going to work.  Without direct authority to make change happen, how can the
TC hope to deliver?

Indirect authority.  13 people of influence, with on-the-ground support
developed and maintained at the project level, pulling in the same direction.
That's the real power of the TC.  And that's the power we're going to use to
effect real change.

This power is created by each TC member doing the hard work of engaging.  It's
writing, testing, debugging and documenting our software.  It's conversations
with developers, users, distros, and operators.  It's developing an emotional
connection - empathizing - with their constituents as they face the frustration
caused by our community and software.  It's making a difference so that their
opinion is respected.  This is the way things work in the individual projects,
and our TC should differ only in the scale of the problems it tackles.

This reinforces the idea, as has been suggested by other candidates, that the
role of TC member needs to be taken more seriously.  Change will not be decided
because our TC knows best, but because its members collectively have first-hand
experience with the problems at hand, have considered a diversity of potential
solutions, and do the hard work of justifying their conclusions.  Change will
happen not because our TC commands it, but because project-level contributors
have trust in our TC members and value their input.  Only by being more engaged
with the wider community can our TC hope to be an effective force for change.

Respectfully,


Maru


More information about the OpenStack-dev mailing list