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 intention.
Zuul Extraction and the Difficult Nature of Communication
Last Tuesday Morning 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 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 concern that some of the reluctance to talk openly about the change appeared to stem from needing to preserve the potency of a Foundation marketing release.
I expressed some frustration: "...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 out, 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 thread on the operators list that raises the potential of merging the Ops Meeting and the PTG into some kind of "OpenStack Community Working Gathering".
Encouraging Upstream Contribution
On Friday, tbarron raised some interesting questions about how the summit talk selection process might relate to the four opens. 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.
I had a question at this morning's office hour, 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 instructive.
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 happen.
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.