Open Stack

Excerpts from Adam Lawson's message of 2015-04-29 11:34:40 -0700:
> So I started replying to Doug's email in a different thread but didn't want
> to hi-jack that so I figured I'd present my question as a more general
> question about how voting is handled for the TC.
> 
> Anyway, I find it curious that the TC is elected by those within the
> developer community but TC candidates talk about representing the operator
> community who are not allowed to vote. Operators meaning Admins,
> Architects, etc. It sounds like this is something most TC candidates want
> which most would agree is a good thing. At least I think so. ; )

I'm going to nitpick on terminology a bit. The TC is elected by
*technical contributors*, not developers, as described in the charter:
http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc

The easy measure of whether someone is an ATC is the first rule listed
there:

  Individual Members who committed a change to a repository under
  ‘’any’’ of the official OpenStack Project Teams (as defined above) over
  the last two 6-month release cycles are automatically considered ATC.

That's the rule most of us remember, and think of when we think of
ATC, but not everyone who does that is a "developer" and landing a
patch is not the only way to become an ATC, as the next sentence
shows:

  Specific contributors who did not have a change recently accepted in
  one of the OpenStack projects but nevertheless feel their contribution
  to the OpenStack project is technical in nature (bug triagers,
  technical documentation writers...) can exceptionally apply for ATC
  either by sending an email to the TC chair or by being nominated by an
  existing ATC via email to the TC chair.

We have a not-very-long list of folks who have that status in
http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs

> Is it be feasible to start allowing the operator community to also cast
> votes for TC candidates? Is the TC *only* addressing technical concerns
> that are relevant to the development community? Since the TC candidates are
> embracing the idea of representing more than just the developer community,
> it would /seem/ the voters electing the TC members should include the
> communities being represented. If the TC only addresses developer concerns,
> it would seem they become at risk of losing touch with the
> operator/architecture/user concerns because the operator community voice is
> never heard in the voting booth.

The TC represents the contributors to the project. That term can
be defined very broadly, as explained above, but I don't think we
want it to be completely open-ended because the issues the TC tries
to resolve *are* from the contributors' perspectives, and not every
user or deployer's perspective. That's not to say those groups don't
have valid concerns, or that the TC would ignore them, just that
the TC is not specifically organized to represent them.

I would rather we explore more ways to identify people we consider to be
contributors than to change the existing voting rules to allow more
people. I think it will amount to the same change in the electorate, and
I like the idea of adding more contributors to the project more than
just adding more voters. :-)

Doug

> 
> Perhaps this bumps into how it used to be versus how it should be. I don't
> know. Just struck me as incongruent with the platform of almost every
> candidate - broadening representation while the current rules prohibit that
> level of co-participation.
> 
> Thoughts?
> 
> 
> *Adam Lawson*
> 
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072