[openstack-dev] [tc] [all] TC Report 18-25
Over the time that I've been observing the TC, there's been quite a
lot of indecision about how and when to exercise power. The rules
and regulations of OpenStack governance have it that the TC has
pretty broad powers in terms of allowing and disallowing projects to
be "official" and in terms of causing or preventing the merging of
_any_ code in _any_ of those official projects.
Unfortunately, the negative aspect of these powers make them the
sort of powers that no one really wants to use. Instead the TC has a
history of, when it wants to pro-actively change things, using
techniques of gently nudging or trying to make obvious activities
that would be useful. [OpenStack-wide
goals](https://governance.openstack.org/tc/goals/index.html) and the
are examples of this sort of thing.
Now that OpenStack is no longer sailing high on the hype seas,
resources are more scarce and some tactics and strategies are no
longer as useful as they once were. Some have expressed a desire for
the TC to provide a more active leadership role. One that allows the
community to adapt more quickly to changing times.
There's a delicate balance here that a few different conversations
in the past week have highlighted. [Last
a discussion about the (vast) volume of code getting review and
merged in the nova project led to some discussion on how to either
enforce or support a goal of decomposing nova into smaller,
less-coupled pieces. It was hard to find middle ground between
outright blocking code that didn't fit with that goal and believing
nothing could be done. Mixed in with that were valid concerns that
the TC [shouldn't be parenting people who are
and [is unable to be
(_Note: the context of those two linked statements is very
important, lest you be inclined to consider them out of context._)
some discussion about keeping the help wanted list up to date led to
thinking about ways to encourage reorganizing "[work around
objectives rather than code
despite that being a very large cultural shift that may be very
difficult to make.
So what is the TC (or any vaguely powered governance group) to do?
We have some recent examples of the right thing: These are written
worksâ??some completed, some in-progressâ??that layout a vision of how
things could or should be that community members can react and refer
to. As concrete documents they provide what amounts to an evolving
constitution of who we are or what we intend to be that people may
point to as a third-party authority that they choose to accept,
reject or modify without the complexity of "so and so saidâ?¦".
* [Written principles for peer
review](https://governance.openstack.org/tc/reference/principles.html#we-value-constructive-peer-review) and [clear documentation](https://docs.openstack.org/project-team-guide/review-the-openstack-way.html) of the same.
* Starting a [Technical Vision for
* There should be more here. There will be more here.
Many of the things that get written will start off wrong but the
only way they have a chance of becoming right is if they are written
in the first place. Providing ideas allows people to say "that's
right" or "that's wrong" or "that's right, except...". Writing
provides a focal point for including many different people in the
generation and refinement of ideas and an archive of long-lived
meaning and shared belief. Beliefs are what we use to choose
between what matters and what does not.
As the community evolves, and in some ways shrinks while demands
remain high, we have to make it easier for people to find and
understand, with greater alacrity, what we, as a community, choose
to care about. We've done a pretty good job in the past talking
about things like the [four
but now we need to be more explicit about what we are making and how
we make it.
Chris Dent Ù©â??Ì¯â??Û¶ https://anticdent.org/
freenode: cdent tw: @anticdent