Jump to: navigation, search

Difference between revisions of "PTL Elections April 2015"

(Adds confirmed candidates)
(Adds Congress project)
Line 40: Line 40:
 
* OpenStack Containers Service (Magnum) - one position
 
* OpenStack Containers Service (Magnum) - one position
 
* Application Catalog (Murano) - one position
 
* Application Catalog (Murano) - one position
 +
* Non-Domain Specific Policy Enforcement (Congress) - one position
  
  
Line 97: Line 98:
 
** [http://lists.openstack.org/pipermail/openstack-dev/2015-April/060515.html Adrian Otto]
 
** [http://lists.openstack.org/pipermail/openstack-dev/2015-April/060515.html Adrian Otto]
 
* Application Catalog (Murano)
 
* Application Catalog (Murano)
 +
* Non-Domain Specific Policy Enforcement (Congress)
  
 
NB: any tie should be broken using [[Governance/TieBreaking]].
 
NB: any tie should be broken using [[Governance/TieBreaking]].
  
 
[[Category:Elections]]
 
[[Category:Elections]]

Revision as of 15:38, 7 April 2015

PTL Elections April 2015

Officials

  • Tristan Cacqueray (tristanC) tristan dot cacqueray at enovance dot com
  • Elizabeth K. Joseph (pleia2) lyz at princessleia dot com

Election System

Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance/TieBreaking.

Timeline

  • April 2 - April 9, 05:59 UTC: Open candidacy for PTL positions
  • April 10 - April 16: PTL elections

Elected Positions

Every official project team must elect a PTL. PTLs are elected for 6 months:

  • Compute (Nova) - one position
  • Object Storage (Swift) - one position
  • Image Service (Glance) - one position
  • Identity (Keystone) - one position
  • Dashboard (Horizon) - one position
  • Networking (Neutron) - one position
  • Block Storage (Cinder) - one position
  • Metering/Monitoring (Ceilometer) - one position
  • Orchestration (Heat) - one position
  • Database Service (Trove) - one position
  • Bare metal (Ironic) - one position
  • Common Libraries (Oslo) - one position
  • Infrastructure - one position
  • Documentation - one position
  • Quality Assurance (QA) - one position
  • Deployment (TripleO) - one position
  • Release cycle management - one position
  • Message Service (Zaqar) - one position
  • Data Processing Service (Sahara) - one position
  • Key Management Service (Barbican) - one position
  • DNS Services (Designate) - one position
  • Shared File Systems (Manila) - one position
  • Command Line Client (OpenStackClient) - one position
  • OpenStack Containers Service (Magnum) - one position
  • Application Catalog (Murano) - one position
  • Non-Domain Specific Policy Enforcement (Congress) - one position


Reference: http://governance.openstack.org/reference/projects/index.html

Electorate

Except otherwise-noted in the project team description, the electorate for a given PTL election are the Foundation individual members that are also committers for one of the team's repositories over the Juno-Kilo timeframe (April 9, 2014 06:00 UTC to April 9, 2015 05:59 UTC).

The electorate is requested to confirm their email address in gerrit, review.openstack.org > Settings > Contact Information > Preferred Email, prior to April 9, 2015 05:59 UTC so that the emailed ballots are mailed to the correct email address.

There is a resolution to the governance repo that all of the electorate is expected to follow: http://governance.openstack.org/resolutions/20140711-election-activities.html

Candidates

Any member of an election electorate can propose their candidacy for the same election until April 9, 05:59 UTC. Self-nomination is common, third party nomination is not required, and on-list candidate support emails are discouraged both to reduce mailing list traffic and to keep everything fair for nominees. Nominees propose their candidacy by sending an email to the openstack-dev@lists.openstack.org mailing-list, which the subject: "ProjectTeam PTL candidacy" (for example for Glance: "Glance PTL candidacy"). The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate.

There is a resolution to the governance repo in case a project team is leaderless: http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

Confirmed candidates:

NB: any tie should be broken using Governance/TieBreaking.