[Openstack-operators] [openstack-dev] [tc] Who is allowed to vote for TC candidates

Doug Hellmann doug at doughellmann.com
Fri May 1 22:14:22 UTC 2015

Excerpts from Adam Lawson's message of 2015-05-01 14:50:33 -0700:
> I purposely didn't email the general mailing list since I didn't want to
> cross-post, hard to have these discussions across verticals and choosing
> one list = hearing one community - those subscribed to the developer
> mailing list.
> So I'm not assuming anything, it seems some are suggesting that Operators
> get into code review to quantify their role as an engaged Operator. Is that
> a correct statement? Just want to make sure I'm hearing correctly. I try to
> avoid absolutes but personally speaking for the record, I don't believe the
> answer lies with asking Operators to become code reviewers on top of
> everthing else they're doing in order for them to have a voice in the TC
> elections. If code reviews are being suggested (again, assuming the
> assumption is correct for the sake of making my point), technical
> contribution extends far beyond uploading and reviewing code. This
> alternate means to gain ATC status seems like a potential candidate for
> those who want to review code but not for those who are day-to-day
> operators engaging with the community.

No, that's not what is being proposed at all.

I am trying to point out that there is already a way to gain
ATC status without having to commit anything to a git repository
(code or otherwise), and so coming up with a way to work within the
existing system may achieve the original goal of allowing some
operators to vote for TC candidates, without having to change our
voting rules.

I want Operators to review *specs*, which aren't code but are *plans*
for code. Having feedback on those plans, either indicating that
they are good or are missing the mark, would be really valuable.
We happen to use the same tool for reviewing those specs as for
reviewing code, but they are written in plain text and the review
tool is a web page so it doesn't require you to install anything
or work with code in any way.

Code review seems further outside of the wheelhouse of most operators,
so while I would welcome it, I don't really expect it and I don't
think it's necessary.

Granting ATC status to folks who aren't committing to repositories
is up to the PTL of each project, and contributing to spec reviews
is an obvious way to demonstrate a level of engagement I would
expect (as a former PTL), project leads to be looking for. We have
a couple of examples of folks who have done this already, so I also
know that it can work for at least some people.

I'm also interested in understanding more directly why you think
having an impact on the TC membership will have a direct effect on
any of the work of the projects. Can you comment more on that?

> Is there any meetings planned in Vancouver where users/operators are
> meeting where we can add an agenda items to gather input?

There is an entire track of operator-led and focused discussions
(I believe this is the third summit where we have had an "ops
track").  It looks like [1] may be the original post where Tom
started gathering ideas for this summit, but I hope someone else
more directly involved corrects me if there is a better starting
point at this stage in the planning.


[1] http://lists.openstack.org/pipermail/openstack-operators/2015-March/006607.html

> Given this conversation involves the Operator community as well, I went
> ahead and CC'd them to hopefully capture their specific thoughts/ideas on
> the subject.
> Mahalo,
> Adam
> *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
> On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg <morgan.fainberg at gmail.com>
> wrote:
> >
> >
> > On Friday, May 1, 2015, Russell Bryant <rbryant at redhat.com> wrote:
> >
> >> On 05/01/2015 02:22 PM, Tim Bell wrote:
> >> >
> >> > The spec review process has made it much easier for operators to see
> >> > what is being proposed and give input.
> >> >
> >> > Recognition is a different topic. It also comes into who would be the
> >> > operator/user electorate ? ATC is simple to define where the equivalent
> >> > operator/user definition is less clear.
> >>
> >> I think spec review participation is a great example of where it would
> >> make sense to grant extra ATC status.  If someone provides valuable spec
> >> input, but hasn't made any commits that get ATC status, I'd vote to
> >> approve their ATC status if proposed.
> >
> >
> > This is exactly the case for David Chadwick (U of Kent) if anyone is
> > looking for prior examples of someone who has contributed to the spec
> > process but has not landed code and has received ATC for the contributions.
> >
> > This is a great way to confer ATC for spec participation.
> >
> > --Morgan
> >
> >
> >> --
> >> Russell Bryant
> >>
> >> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

More information about the OpenStack-operators mailing list