[openstack-dev] [ptl][requirements] nomination period started
doug at doughellmann.com
Thu Jul 28 16:42:32 UTC 2016
Excerpts from Anita Kuno's message of 2016-07-28 12:21:26 -0400:
> On 07/27/2016 06:06 PM, Jeremy Stanley wrote:
> > On 2016-07-27 17:56:39 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >> However, we may have some folks on the core team who have not
> >> contributed a patch, since it is far more common to do reviews than
> >> to submit changes there (more and more of the changes are being
> >> automated). So, we probably need to expand the traditional definition
> >> to also include the existing core review team (members of
> >> requirements-core ), just to be safe.
> > [...]
> > Easy enough to do for a one-off, but might want to consider
> > officially adding them as extra-ATCs in governance down the road to
> > make that more explicit. Our existing tooling is already adapted to
> > that solution as well (for example, the current i18n voters are
> > _all_ recorded as extra-ATCs because we haven't implemented API
> > calls to Zanata for integrating it into the normal roll generation
> > process yet).
> > However, implicitly adding core reviewers seems a little weird as
> > they're officially appointed by the PTL and so allowing the
> > incumbent PTL to appoint (or remove) specific voters before their
> > pending reelection... well anyway, I guess it's balanced out by
> > there being a lot more committers to that repo than core reviewers
> > on it.
> So Doug and I had a chat and we propose the following workflow for
> deciding the requirements ptl:
> 1) Nominations open, done:
> 2) Nominations close: August 5th, 11:59 utc
> 3) List of Nominees posted to mailing list, a post appened to the
> 4) Election officials start civs poll after 13:00 utc August 5, 2016
> 5) Election poll closes after 13:00 utc August 11, 2016
> 6) Winning candidate will be announced to the mailing list
> (openstack-dev at lists.openstack.org)
> requirements core reviewers and those who have merged at least one
> patch to the requirements repo between 1 Aug 2015 and July 31 2016
As part of our discussion, we realized that over time we'll be
automating more and more of the submissions to the requirements
repo so the core review team (and everyone else) will likely end
up submitting fewer manual patches. This points out a difference
in the nature of this team from others that we'll need to address
to avoid arriving at the unlikely situation where no human is
actually able to vote for PTL. It's more likely that none of the
core review team would be on the voter list using our usual "who
has landed a patch" rule, and that would be bad as well, IMO.
So, the new team will need to add an item to their bootstrapping
todo list to specify how their electorate is identified to ensure
we can continue to have healthy, representative, elections. Based
on my interpretation of the TC charter , we don't need a rules
change. Adding some team documentation and (as Jeremy pointed out)
active maintenance of the "extra-atcs" list for the team in the
governance repository should be sufficient.
I propose that we defer any real discussion of what the policy
should be until after the current election, but try to work it out
before the team applies for big tent membership.
> can I vote?
> how do I vote?
> eligible voters will receive a ballot sent to their gerrit preferred
> email, if you are an eligible voter and don't receive an email providing
> you a link to the poll by August 6, 2016 please email the election
> officials with a gerrit url for your patch confirming your eligibility
> Please ask any questions you need to ask to clarify this process so you
> understand it.
> If you have a question of a personal nature, please don't hesitate to
> email both election officials: Doug Hellmann <doug at doughellmann.com> and
> Anita Kuno <anteaya at anteaya dot info> as soon as you can so we can
> ensure you have the answers you need.
> Thank you to Jeremy Stanley for his assistance and support as well as
> his offer to help us generate the electoral rolls, which include a wip
> patch to governance to generate an electoral roll separate from the
> Release Management team electorate. After the election, we will abandon
> that patch and let the new team propose its own change, including a
> mission statement and other metadata, when they seek to become a big
> tent project. Gerrit patch: https://review.openstack.org/#/c/348462
> Thanks for your participation in the electoral process,
> Anita and Doug
More information about the OpenStack-dev