The first TC Report was published in late April of 2017. What follows is a review of the issues and persistent themes that distill out of a read through all the reports since then.

As with the reports themselves, this is a biased and opinionated document in which I'll editorialize on my own editorializing. I've had plenty of feedback that says that being biased and opinionated helps to keep the reports interesting, useful, and something other than terribly dry. I also hope that it helps to draw in people who may have different opinions. The point of these things has been to increase awareness and communication, for and from everyone.

If you need a TL;DR, jump ahead to Decoupling.

Shift in TC Membership

Following the rules, there were two TC elections in 2017. In both, especially the second, there was a bit of a shift in the candidate pool and in those eventually elected. Some old timers stepped aside, breaking the usual trend of incumbency equaling persistence. The new membership, along with the change to office hours, has helped to drive a renewed desire for activism that's been tempered a bit by difficulty with gaining traction and trouble finding the necessary levers and fulcrums.

Influencing Corporate Contribution

An area where more action has been desired is influencing the volume and type of corporate contribution, in a more effective fashion. This has been a theme throughout office hours, PTG meetings, and discussions leading up to and following board meetings: How can the TC, and by extension the technical contributors they represent, effectively influence how the corporate Foundation members and other OpenStack corporate stakeholders manage the staff they require or allow to contribute upstream.

The Help most needed list (née "Top 5 help wanted"), OpenStack-wide goals, and TC Vision have helped illuminate some areas that need attention, but the way this topic keeps coming up suggests that more work is needed. The problem is not simply one of getting more resources. It is just as much an issue of achieving some goals that are actually shared, OpenStack-wide, about what OpenStack is or should become.

There's been some agreement that reaching this requires vastly more and more open communication amongst all the people who are involved.

That Vision Thing

The original version of the TC Vision, drafted in the first half of 2017, was edited in the second half to give it a more straightforward style to make it more amenable to skimming and goal creating. This came at the cost of removing some of the reasoning surrounding the goals.

Some progress has been made on the goals implied by the vision. Using bits and pieces of OpenStack independently is on the rise. Relationships and collaboration with adjacent technical communities has been improved. Greater attention is being given to issues with diversity in the community. There is increased awareness of the need to actively encourage and enable new leaders.

However, there is plenty left to do. There was a great deal of positive feedback on the idea of "constellations" but we're some distance away from having the "orion" website that people hoped to see. We've built some very positive bridges with the Kubernetes community, but there were reports from Kubecon that OpenStack is often whipped as the convenient down dog. We're making headway, but have a long way to go before we have anything like truly diverse (gender, ethnic, geographic) representation in the TC and with PTLs and project cores. While new faces are very welcome, it's still often the case that the same heroes are occupying leadership and driver roles.

Maintenance Mode

Midway through the year there was plenty of discussion on the meaning and usefulness of a maintenance-mode tag. It's used to indicate a project that is in a period of low-activity, but is sometimes interpreted as a negative. Some of the debate centered around why that should be: For some, low activity can mean "works so well, no changes are required".

This is relevant as OpenStack reaches a form of maturity. Not all projects will always see a constant flow of contributions, but they may still adequately satisfy their use cases.

Meaning of Supported

There were a few different discussions throughout the year about what it means for a technology to be supported. Questions about support for PostgreSQL led to a current level of community support document and a definition of upstream support.

Meanwhile we realized by the end of the year that the strict interpretation of those rules (especially "if it's not tested in CI, it's not supported") is incredibly limiting. Using PostgreSQL can work. Ways of doing skip-level and decoupled upgrades is possible with sufficient effort. Long Term Support (LTS) exists. But these things are not in CI. They are not what OpenStack is, but they are something other people or organizations can do with OpenStack.

What we do with OpenStack in CI is incredible, but it is not a complete picture of what people can do and want to do with OpenStack. It never can be, and never should be. Being tested in the gate should mean just that: It's tested in the gate. The idea that the OpenStack project, at large, provides support, is misplaced.

See also related discussion on whether we actually enable continuous deployment.

TC Communications

In 2017 there were many changes to how the TC communicates. The weekly TC meetings ended, replaced by office hours in a dedicated IRC channel, #openstack-tc. I do my weekly TC Reports. Thierry does a weekly factual summary (see the most recent one) based on a Tracker wiki page.

This has greatly enhanced the opportunity for engagement amongst the members of the TC and with the community. In reality, however, it appears to be that the members of the TC chat a lot in IRC, there is quite a bit of published information, but not huge amounts of lbi-directional communication between the TC and the entirety of the rest of the community.

Bye Bye "big tent"

2017 dismissed the term "big tent". People were often confused about what it meant and sometimes used that ambiguity with ill intent. A final flushing was made to the governance repository. The commit message includes a bit of history.

The term of art these days is "official project", meaning a project that has voluntarily chosen to have the TC as its governing body. Other projects continue to use and are welcome to use OpenStack infrastructure. These are not the same things.

Glare and Mogan

There were many applications by projects to be official, but two of note stalled out: Glare and Mogan. I wrote about this in the context of the TC's power but eventually the proposals were withdrawn by the applicants.

The balance between protecting and ensuring the state of existing projects while allowing and encouraging a measure of innovation and competition is delicate. In this case protectionism won. For some words on this see Dean's comment on patchset 6 on the Glare review. My comment on patchset 2 on the Mogan Review talks about difficulties when trying to include voices from all participants.

SIGs

2017 saw the introduction of Special Interest Groups as one way to make including more voices more direct. They are designed to

Replace UC or TC-side "workgroups" by neutral "SIGs" to encourage wide participation --tracker

Some people had been feeling that the governance of a workgroup was a statement of who was allowed to participate. SIGs are an effort to break down those barriers and remove some of the formalisms that have may have impeded progress in the past.

There is a growing list of SIGs. Most are workgroups that have migrated or combined to become a SIG.

Foundation Expansion

The Foundation grew to add a sibling project, Kata Containers, outside the domain of OpenStack. The sibling will have its own governance. Additional projects may be expected in the future. One candidate topic is edge computing.

Release Cycle Length

Thierry mooted the idea of extending the release cycle, birthing a monster email thread. In that thread, and the related IRC discussions vast numbers of ideas and concerns were raised. It's not entirely clear what the outcome was, but my interpretation was that the concerns were valid, but extending the release cycle would not solve them, more investigation needed.

Decoupling

Perhaps it is time we consider decoupling the development cycle from the release cycle and both from the consumption cycle (this is already true in practice)? And consider breaking other forms of coupling such as requiring stabilized projects to release, upgrades of service A requiring upgrades of service B, or downstream support requiring upstream testing.

Use of OpenStack is growing, but development of it is not. We must adapt our habits.

Feedback Loops

If I had to identify a common thread throughout these many topics, it is that in those situations where we have had active feedback loops with keen interest to reach resolutions, we have made progress and improved things. Where feedback has not happened, or has stalled, issues have lingered and often compounded. We are often too distracted by immediate needs to the detriment of long term health and stability. Solving today's tactical crises must be balanced with the hard work of talking through the many layers of cause and effect that make today what it is and control what tomorrow will be. There's a bit more on that in the last report of the year.

Fidelity of communication in terms of requirements and roadblocks, from all parties, in all directions, is low.

We can improve many of the things people have been talking about, but it's going to take a lot of discussion to reach agreement on what each of the problems really are. Historically we have not been that good, as a community, at accepting that broadly ranging conversations are an okay use of time.

They are. They help us develop the shared language that is critical to developing the shared understanding that is required to establish shared goals.

Running for the Board

The need and hope for high-fidelity communication and true bi-directional feedback between contributors and the TC is why I ran for the TC and started writing the TC Report.

The same thing is needed with the Foundation board: rigorous, active, and transparent feedback that represents the concerns of the active technical community. Sean McGinnis and I spoke about this and agreed we should both run to be Individual Member directors on the board. Elections are next week (January 8-12), if you have been an individual member of the Foundation since before July 17, 2017 you should receive a ballot Monday the 8th. There are many excellent candidates. If neither Sean nor I appeal, we won't be offended, but please vote; the Foundation has a significant impact on the shape and activities of the community.

End Note

If you want or need further context on anything here, the entire collection of TC reports is available on the 'tc' tag.