( rendered: https://anticdent.org/tc-report-40.html )
This week opens OpenStack Technical Committee (TC) election season.
There's an [announcement email
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-October/122933.html)
(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](https://governance.openstack.org/election/#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](https://ttx.re/role-of-the-tc.html):
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](http://lists.openstack.org/pipermail/openstack-dev/2017-October/122962.html).
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](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-03.log.html#t2017-10-03T09:01:27)
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](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-09-27.log.html#t2017-09-27T17:15:24)
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](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-09-28.log.html#t2017-09-28T15:01:35)
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](https://service-types.openstack.org/)
and effectively naming resources when there may be another thing that
wants to use a similar name for not quite the same purpose.
--
Chris Dent (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
