Open Stack

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

Trying to write a TC report after a gap of 3 weeks is hard enough,
but when that gap involves some time off, the TC elections, and the
run up to summit (next week in
[Vancouver](https://www.openstack.org/summit/vancouver-2018/)) then
it gets bewildering. Rather than trying to give anything like a full
summary, I'll go for some highlights.

Be aware that since next week is summit and I'll be travelling the
week after, there will be another gap in reports.

# Elections

The elections were for seven positions. Of those, three are new to
the TC: Graham Hayes, Mohammed Naser, Zane Bitter. Having new people
is _great_. There's a growing sense that the TC needs to take a more
active role in helping adapt the culture of OpenStack to its
changing place in the world (see some of the comments below). Having
new people helps with that greatly.

Doug Hellman has become the chair of the TC, taking the seat long
held by Thierry. This is the first time (that I'm aware of) that a
non-Foundation-staff individual has been the chair.

One of the most interesting parts of the election process were the
email threads started by Doug. There's hope that existing TC
members that were not elected in this cycle, those that have
departed, and anyone else will provide their answers to them too. An
[email
reminder](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130382.html)
exists.

# Summit

Is next week, in Vancouver. The TC has several
[Forum](https://wiki.openstack.org/wiki/Forum/Vancouver2018)
sessions planned including:

* [S release
   goals](https://etherpad.openstack.org/p/YVR-S-release-goals)
* [Project boundaries and what is
   OpenStack](https://etherpad.openstack.org/p/YVR-forum-TC-project-boundaries)
* [TC
   Retrospective](https://etherpad.openstack.org/p/YVR-tc-retrospective)
* [Cross Community
   Governance](https://etherpad.openstack.org/p/YVR-cross-osf-tech-governance)

# Corporate Foundation Contributions

There's ongoing discussion about how [to
measure](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-24.log.html#t2018-04-24T15:43:59)
upstream contribution from corporate Foundation members and what to
do if contribution seems lacking. Part of the reason this came up
was because the mode of contribution from new platinum member,
Tencent, is not clear. For a platinum member, it should be
_obvious_.

# LCOO

There's been some concern expressed about the The Large Contributing
OpenStack Operators (LCOO) group and the way they operate. They use
an [Atlassian Wiki](https://openstack-lcoo.atlassian.net/) and
Slack, and have restricted membership. These things tend to not
align with the norms for tool usage and collaboration in OpenStack.
This topic came up in [late
April](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-04-26.log.html#t2018-04-26T14:39:36)
but is worth revisiting in Vancouver.

# Constellations

One of the things that came out in election campaigning is that
OpenStack needs to be more clear about the many ways that OpenStack
can be used, in part as a way of being more clear about what
OpenStack _is_. Constellations are one way to do this and work has
begun on one for [Scientific
Computing](https://review.openstack.org/#/c/565466/). There's some
discussion there on what a constellation is supposed to accomplish.
If you have an opinion, you should comment.

# Board Meeting

The day before summit there is a "combined leadership" meeting with
the Foundation Board, the User Committee and the Technical
Committee. Doug has posted a [review of the
agenda](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130336.html).
These meetings are open to any Foundation members and often involve
a lot of insight into the future of OpenStack. And snacks.

# Feedback, Leadership and Dictatorship of the Projects

Zane started [an email
thread](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130375.html)
about ways to replace or augment the once large and positive
feedback loop that was present in earlier days of OpenStack. That
now has the potential to trap us into what he describes as a "local
maximum". The thread eventually evolved into concerns that the
individual sub-projects in OpenStack can sometimes have too much
power and identity compared to the overarching project, leading to
isolation and difficulty getting overarching things done. There was a
bit of discussion about this [in
IRC](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-11.log.html#t2018-05-11T19:13:02)
but the important parts are in the several messages in the thread.

Some people think that the community goals help to fill some of this
void. Others thinks this is not quite enough and perhaps project
teams as a point of emphasis is ["no longer
optimal"](http://lists.openstack.org/pipermail/openstack-dev/2018-May/130436.html).

But in all this talk of change, how do we do the work if we're
already busy? What can we not do? That was a topic [Monday
morning](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-14.log.html#t2018-05-14T09:00:00).

# API Version Bumps

Also on Monday, plans [were
made](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-14.log.html#t2018-05-14T17:27:05)
to have a session in Vancouver about how to do across-the-system
minimum API version bumps. This started in response to a meandering
thread [on
twitter](https://twitter.com/robcresswell/status/994911766776877059)
about inconsistencies in the OpenStack's APIs "never" being
resolved.

# Where Now?

It's hard to make any conclusions from the election results. A
relatively small number of people voted for a relatively small
number of candidates. And there's always the sense that voting is
primarily based on name recognition where platforms and policies
have little bearing. However, if we are to take the results at face
value then it appears that at least some of the electorate wants one
or both of the following from the TC:

* Increased communication and engagement.
* Greater and more active exercising of whatever power they can
   dredge up to help lead and change the community more directly.

Do _you_ think this is true? What direction do things need to go?

I'm currently in the state of mind where it is critical that we
create and maintain the big picture information artifacts
("OpenStack is X, Y, and Z", "OpenStack is not A, B and C", "Next
year OpenStack will start being E but will stop being Z") that allow
contributors of any sort to pick amongst the (too) many
opportunities for things to do. Especially making it easier—and
socially and professionally _safer_—to say "no" to something. This
makes it more clean and clear to get the right things done—rather
than context switch—and to create the necessary headspace to
consider improvements rather than doing the same thing over again.

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