This week opens OpenStack Technical Committee (TC) election season. There's an announcement email thread (note the followup with some corrections). Individuals in the OpenStack community may self-nominate up until 2017-10-08, 23:45 UTC. There are instructions for how to submit your candidacy.

If you are interested you should put yourself forward to run. The TC is better when it has a mixture of voices and experiences. The absolute time commitment is less than you probably think (you can make it much more if you like) and no one is expected to be a world leading expert in coding and deploying OpenStack. The required experience is being engaged in, with, and by the OpenStack community.

Election season inevitably leads to questions of:

• what the TC is designed to do
• what the TC should do
• what the TC actually did lately

A year ago Thierry published What is the Role of the OpenStack Technical Committee:

Part of the reason why there are so many misconceptions about the role of the TC is that its name is pretty misleading. The Technical Committee is not primarily technical: most of the issues that the TC tackles are open source project governance issues.

Then this year he wrote Report on TC activity for the May-Oct 2017 membership.

Combined, these go some distance to answering the design and actuality questions.

The "should" question can be answered by the people who are able and choose to run for the TC. Throughout the years people have taken different approaches, some considering the TC a sort of reactive judiciary that mediates and adjudicates disagreements while others take the view that the TC should have a more active and executive leadership role.

Some of this came up in today's office hours where I reported participating in a few conversations with people who felt the TC was not relevant, so why run? The ensuing conversation may be of interest if you're curious about the intersection of economics, group dynamics, individualism versus consensualism in collaborative environments, perception versus reality, and the need for leadership and hard work.

Other Topics

Conversations on Wednesday and Thursday of last week hit a couple of other topics.

LTS

On Wednesday the topic of Long Term Support came up again. There are effectively two camps:

• Those who wonder why this should be an upstream problem at all, as long as we are testing upgrades from N-1 we're doing what needs to be done.

• Those who think that if multiple companies are going to be working on LTS solutions anyway, wouldn't it be great to not duplicate effort?

And we hear reports of organization that want LTS to exist, but are not willing to dedicate resources to see it happen, evidently still confusing large-scale open source with "yay! I get free stuff!".

Overlapping Projects

On Thursday we discussed some of the mechanics and challenges when dealing with overlapping projects in the form of Trove and a potential new database-related project with the working title of "Hoard". Amongst other things there's discussion of properly using the service types authority and effectively naming resources when there may be another thing that wants to use a similar name for not quite the same purpose.