[openstack-dev] [tc] [all] TC Report 18-12

Chris Dent cdent+os at anticdent.org
Tue Mar 20 23:24:19 UTC 2018

HTML: https://anticdent.org/tc-report-18-12.html

This week's TC Report goes off in the weeds a bit with the editorial
commentary from yours truly. I had trouble getting started, so had
to push myself through some thinking by writing stuff that at least
for the last few weeks I wouldn't normally be including in the
summaries. After getting through it, I realized that the reason I
was struggling is because I haven't been including these sorts of
things. Including them results in a longer and more meandering report
but it is more authentically my experience, which was my original

# Zuul Extraction and the Difficult Nature of Communication

Last [Tuesday
we had some initial discussion about Zuul being extracted from
OpenStack governance as a precursor to becoming part of the CI/CD
strategic area being born elsewhere in the OpenStack Foundation.

Then on [Thursday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-03-15.log.html#t2018-03-15T15:08:06)
we revisited the topic, especially as it related to how we
communicate change in the community and how we invite participation
in making decisions about change. In this case by "community" we're
talking about anything under the giant umbrella of "stuff associated
with the OpenStack Foundation".

Plenty of people expressed that though they were not surprised by
the change, it was because they are insiders and could understand
how some, who are not, might be surprised by what seemed like a big
change. This led to addressing the immediate shortcomings and
clarifying the history of the event.

There was also
that some of the reluctance to talk openly about the change appeared
to stem from needing to preserve the potency of a Foundation marketing

I [expressed some
"...as usual, we're getting caught up in
details of a particular event (one that in the end we're all happy
to see happen), rather than the general problem we saw with it
(early transparency etc). Solving the immediate problem is easy, but
since we _keep doing it_, we've got a general issues to resolve."

We went round and round about the various ways in which we have tried
and failed to do good communication in the past, and while we make
some progress, we fail to establish a pattern. As Doug [pointed
no method can be 100% successful, but if we pick a method and stick to
it, people can learn that method.

We have a cycle where we not only sometimes communicate poorly but
we also communicate poorly about that poor communication. So when I
come round to another week of writing this report, and am reminded
that these issues persist and I am once again communicating about
them, it's frustrating. Communicating, a lot, is generally a good
thing, but if things don't change as a result, that can be a strain.
If I'm still writing these things in a year's time, and we haven't
managed to achieve at least a bit more grace, consistency, and
transparency in the ways that we share information within and
between groups (including, and maybe especially, the Foundation
executive wing) in the wider community, it will be a shame and I will
have a sad.

In a somewhat related and good sign, there is [great
on the operators list that raises the potential of merging the Ops
Meeting and the PTG into some kind of "OpenStack Community Working

# Encouraging Upstream Contribution

tbarron raised some interesting questions about how the summit talk
selection process might relate to the [four
opens](https://governance.openstack.org/tc/reference/opens.html).  The
talk eventually led to a positive plan to try bring some potential
contributors upstream in advance of summit as, well as to work to
create more clear guidelines for track chairs.

# Executive Power

I had a question at [this morning's office
related to some work in the API-SIG that hasn't had a lot of traction,
about how best to explain how executive power is gained and spent
in a community where we intentionally spread power around a lot. As
with communication above, this is a topic that comes up a fair
amount, and investigating the underlying patterns can be

My initial reaction on the topic was the fairly standard (but in
different words): If this is important to you, step up and make it

I think, however, that when we discuss these things we fail to take
enough account of the nature of OpenStack as a professional open
source environment. Usually, nonhierarchical, consensual
collaborations are found in environments where members represent
their own interests.

In OpenStack our interactions are sometimes made more complex (and
alienating) by virtue of needing to represent the interests of a
company or other financial interest (including the interest of
keeping our nice job) while at the same time not having the recourse
of being able to complain to someone's boss when they are difficult
(because that boss is part of a different hierarchy than the one you
operate in). We love (rightfully so) the grand project which is
OpenStack, and want to preserve and extend as much as possible the
beliefs in things that make it feel unique, like "influence tokens".
But we must respect that these things are collectively agreed
hallucinations that require regular care and feeding, and balance
them against the surrounding context which is not operating with
those agreements.

Further, those of us who have leeway to spend time building
influence tokens are operating from a position of privilege. One of
the ways we sustain that position is by behaving as if those tokens
are more readily available to more people than they really are.

/me wipes brow

# TC Elections Coming

The next round of TC elections will be coming up in late April. If
you're thinking about it, but feel like you need more information
about what it might entail, please feel free to contact me. I'm sure
most of the other TC members would be happy to share their thoughts
as well.

Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

More information about the OpenStack-dev mailing list