tsc_election_proposal.wiki

== Overview ==

This page is a part of the OpenDaylight community's attempts at refactoring the OpenDaylight Technical Steering Committee (TSC) election system. It provides background information, guiding principles, a "framework" of ideas that have consensus, framework amendment proposals where consensus is unclear and specific seat allocation proposals for the current election.

Please feel encouraged to make edits, no matter your position in the ODL Community. The wiki's version control can be used to track changes.

== Background ==

When OpenDaylight was initially bootstrapped, there wasn't an existing technical community to draw Technical Steering Committee (TSC) leadership from. The initial TSCs were bootstrapped with Platinum Designates, one per by OpenDaylight Platinum Member Company. The intention at the time and since has been to move away from Platinum Designates towards community-elected representatives once the community was mature enough to provide the required leaders.

This need to refactor the TSC's election system was made more pressing by [https://lists.opendaylight.org/pipermail/tsc/2015-October/004026.html recent attempts to avoid an undesirable feature of the TSC election system] with a recurring waver, which the OpenDaylight Board rightly pointed out amounted to bypassing the TSC's charter instead of fixing it.

== Principles ==

This section documents ''why'' we designed the election system we did.

=== Representation of Constituencies ===

OpenDaylight is made up of groups that sometimes want different things from the TSC. These Constituencies should be represented at the TSC.

=== Election by Community Peers ===

Representatives to the TSC should be elected by their peers in the OpenDaylight community on the basis of merit. Now that OpenDaylight is a more mature project with a large and healthy community to draw leadership from, non-elected bootstrap positions like Platinum Designates can be supplemented or replaced.

=== Protection from Dominance by a Constituency ===

No single Constituency should be able to dominate the TSC.

=== Fairness of Exclusion ===

Candidates should be excluded from the possibility of holding a TSC seat they would have otherwise won as infrequently as possible, and only for the sake of trade-offs with other key principles. When some candidates must be excluded from holding seats, the selection should be done as fairly as possible (consensus, merit, random, not power over career).

=== Modern Election Tools ===

When possible, OpenDaylight's election process should make use of high-quality existing election primitives. For example, proportional representation voting systems for multi-seat constituencies that use ranked voting, like [http://civs.cs.cornell.edu/rp.html Condorcet] or [https://en.wikipedia.org/wiki/Single_transferable_vote Single Transferable Vote], have well-understood good properties that are helpful for our use-case.

=== Flexibility over Time ===

We have an imperfect understanding of what governance structures are best for OpenDaylight and we expect the governance needs of OpenDaylight to change over time. The election system we adopt should enable a clear path for adjustments over time, especially for aspects that are most likely to be dynamic (like seat allocations to Constituencies).

== Framework ==

This framework is meant to include the parts of OpenDaylight's Election Proposal that have consensus. Sections where consensus is still developing are stubbed out with pointers to proposed alternatives.

=== Overview ===

OpenDaylight's Technical Steering Committee will be elected by a set of multi-winner elections, one election per [https://wiki.opendaylight.org/index.php?title=TSC:Election_Proposal#Seat_Allocation Represented Group]. The set of Represented Groups and the number of TSC seats allocated to each will be determined before each election by the outgoing TSC.

=== Frequency ===

TSC elections will happen <TBD see Framework Amendment Proposals#Frequency>.

=== Seat Allocation ===

OpenDaylight TSC seats are allocated to Represented Groups (RGs) of the OpenDaylight community. Represented Groups are typically Constituencies with systematically competing interests that the TSC wants to ensure have voices (in the form of votes). Seats may be allocated to other groups, for example to incentivize behaviors like projects moving to later [https://www.opendaylight.org/project-lifecycle-releases#ProjectTypes ODL Lifecycle states].

Before each election, the outgoing TSC will review and potentially make changes to the allocation of TSC seats.

The seat allocation for an election is defined as a set of Represented Groups, each of which is defined by:

# Min Seats - Minimum number seats allocated to the RG (as a percentage or integer). Provides [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Representation_of_Constituencies Representation of Constituencies] property.
# Max Seats - Maximum number seats that can be held by the RG (as a percentage or integer). Provides [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Protection_from_Dominance_by_a_Constituency Protection from Dominance by a Constituency] property.
# Candidates - Set of people eligible to run for the RG's seats. Provides [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_by_Community_Peers Election by Community Peers].
# Voters - Set of people who can vote in the RG's election. Provides [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Election_by_Community_Peers Election by Community Peers].

=== Election Mechanics ===

OpenDaylight will run a series of elections, one per Represented Group. Each election will have N winners, where N is the Represented Group's "Min Seats" value.

For each Represented Group, the eligible candidates for its seats should be notified of their eligibility and asked to self-nominate. The TSC or some Election Official appointed by the TSC will specify a location to post candidate information (like a wiki), and may additionally suggest (biographical, platform) or require (name, IRC handle) some discretionary information. Self-nominations from candidates must include the set of Represented Groups for which they match the Candidate description and as well as a single Represented Group under which they would like to run for a TSC seat.

The self-nomination phase should remain open for a period that enables eligible candidates from all Represented Groups to complete the process with a reasonable effort. If a Represented Group fails to produce enough self-nominated eligible candidates to fill the seats allocated to it, the TSC should reopen the self-nomination phase, encourage additional nominations and potentially revise the seats allocations for the election.

After the self-nomination phase, for each Represented Group, the eligible voters in its election should be directed to the candidate information and given a ballot for each Represented Group for which they are a member of the electorate. If the Ranked Preference Algorithm tooling supports it, ballots will list all self-nominated eligible candidates in a pseudorandom order. Exact wording for the ballot and other communication can be specified by the TSC or left to an Election Official. Voters vote, and the Ranked Preference Algorithm returns the raked preference results. For each RG, the top "Min Seats" candidates are declared winners pending over-max resolution.

For all Represented Groups, the number of TSC seat winners who meet the Candidates description of the RG (declared during self-nomination) is determined. The actual percentage of representation achieved by each RGs is determined. If the actual percentage of TSC seats won by candidates in a Represented Group is higher than the group's Max Seats allocation, over-max resolution is handled by a Scaled Popularity Election.

Winning candidates are notified, results are publicly posted and the transfer of TSC seats happens immediately.

==== Election Algorithms ====

OpenDaylight's Election Framework allows the specific ranked preference voting algorithm it consumes to be swapped out. This gives the TSC or their Election Official [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Flexibility_Over_Time flexibility over time], allowing the best known algorithm and tooling to be used for each election. This also allows the algorithm and implementation be treated like a black box in the rest of the Election Framework, simplifying user-facing elements by extracting complexity to [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Modern_Election_Tools modern election tools].

For the sake of the rest of the Framework, the specific algorithm and tooling used for a given election will be called the Ranked Preference Algorithm. The properties of modern election algorithms are complex, so the TSC and their Election Official should generally strive to follow modern best practices. The only specific requirement imposed by the way the algorithm is consumed in OpenDaylight's Election Framework is that it must provide a ranked preference result, so the top N candidates can win the N seats in their Represented Group's election.

The [http://civs.cs.cornell.edu/rp.html Condorcet algorithm], with the Condorcet-IRV completion rule, will be used for OpenDaylights first new-style election. Tooling will be provided by the [http://civs.cs.cornell.edu/ Condorcet Internet Voting Service], which is [https://github.com/andrewcmyers/civs open source] and maintained by Cornell. ODL's Elections Framework was originally designed with STV in mind, but no suitable web-based implementation can currently be found and Condorcet may be a more fair algorithm.

==== Over-Max Resolution Through Scaled Popularity ====

After running the elections for all Represented Groups, for any RG that exceeded the Max Seats value, an over-max resolution election is held (using the votes from the full election, no new voting needs to occur) among the winning candidates. Each candidate's vote count is scaled to account for differences in the number of votes cast in their Represented Groups. The resulting counts are used to run a normal Ranked Preference Algorithm election among the over-max RG's winning candidates, with the number of winners equal to the the RG's Max Seats value. After all losing candidates have been determined, they are dropped from the main Represented Group elections they competed in. Elections for all Represented Groups are then re-run. If the new results put a RG above its Max Seats cap, the process repeats until all RG are below their cap. If the pool of self-nominated eligible candidates is exhausted before the process terminates, the outgoing TSC should revisit the company cap size or recruit a more diverse set of candidates.

===== Scaled Popularity Example  =====

As an example, if we had three elections with 4, 8, and 16 voters in each, where we wound up with four candidates from RG A winning, but a cap of three, we would have a special side election to figure out which one should be dropped. This would be done by scaling the candidate's votes by 1/n, where n is the number of voters in the RG, and re-running the Ranked Preference Algorithm election.

So, if the candidates got:
* A.) 2 votes of 4
* B.) 3 votes of 8
* C.) 5 votes of 16
* D.) 3 votes of 16

That would result in candidates having scaled votes of:
* A.) 0.5
* B.) 0.375
* C.) 0.3125
* D.) 0.1875

The result is that person D is eliminated and the main RG elections are re-run.

== Examples ==

=== Basic Example ===

==== Example Seat Allocation ====

* Represented Group A
** Min Seats: 1
** Max Seats: 100%
** Candidates: [list of candidates]
** Voters: [list of 100 voters]

==== Election A ====

All candidates are notified of their eligibility and asked to self-nominate.

Two candidates self-nominate: Candidate AA and Candidate AB.

All voters are given a ballot (basic example below). If the Ranked Preference Algorithm tooling supports it, the order of the candidates vary pseudorandomly per-voter.

 <explanation of TSC elections, links to candidate info, etc>

 Rank the candidates below 1-n, with 1 being the most preferred and n the least preferred.

 * Candidate AA: [_]
 * Candidate AB: [_]

Ballots are distributed by the Ranked Preference Algorithm tooling. Voters complete and submit them. The Ranked Preference Algorithm tooling returns the preference ranking of the candidates, and the top Min Seats candidates (one in this case) are declared winners. Since there's only one RG election, the TSC election process terminates. No RG is exceeding their Max Seats bounds, so no additional action needs to be taken.

== Framework Amendment Proposals ==

The sections here are meant to provide alternatives substitutions into the generally agreed upon framework above.

Please feel encouraged to add your ideas here.

=== Election Frequency ===

How frequently should TSC elections occur? Should they be correlated with some other event, like an [https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Schedule ODL Release Milestone]?

==== Per-Release ====

TSC elections would be held per-release.

A major job of the TSC is to approve a release plan and work through a release. Linking TSC elections and releases seems natural. Having one election to one release provides the quickest possible feedback iterations.

==== Bi-Release ====

TSC elections would be held every two OpenDaylight releases.

With our current six month release cycle, bi-release elections would provide the yearly election frequency prescribed by the [https://www.opendaylight.org/tsc-charter current TSC Charter].

Compared to per-release elections, bi-release would provide slower iterations, but may incur less overhead. Bi-Release elections provide the same natural linking of TSC elections to releases as pre-release elections.

==== Yearly ====

Section 4 of the [https://www.opendaylight.org/tsc-charter current TSC Charter] prescribes yearly elections.

 The term for TSC members, including the Chair, is one year.  There are no term limits for TSC members.

A disadvantage of yearly elections is that they don't necessarily relate to release cycles, so TSCs may be asked to drive releases they didn't plan.

== Represented Group Proposals ==

Represented Groups (seat allocations, eligible candidates and eligible voters) proposals for the first election.

See the [https://wiki.opendaylight.org/view/TSC:Election_Proposal#Seat_Allocation Seat Allocation] section of the framework for details.

Please feel encouraged to add additional proposals.

=== Bit of Everything ===
This proposal allocates seats to most Represented Groups discussed so far. It makes a good example proposal because most other proposals will be subsets of it. To simplify things, all Min Seat counts are set to 1.

For purposes of avoiding domination by any particular RG, Max Seats is uniformly set to 33% for all RGs except Committers-at-Large (since any TSC member elected will be a committer).

 * Committers-at-Large
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: Committers to ODL projects
   * Voters: Committers to ODL projects
 * Core Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Core projects
   * Voters: PTLs of Core projects
 * Mature Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Mature projects
   * Voters: PTLs of Mature projects
 * Incubation Project PTLs
   * Seats: 1
   * Candidates: PTLs of Incubation projects
   * Voters: PTLs of Incubation projects
 * Kernel Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Kernel-type projects
   * Voters: PTLs of Kernel projects
 * Protocol Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Protocol-type projects
   * Voters: PTLs of Protocol projects
 * App Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of App-type projects
   * Voters: PTLs of App projects
 * Support Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Support-type projects
   * Voters: PTLs of Support projects
 * Offset-0 Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Offset-0 projects
   * Voters: PTLs of Offset-0 projects
 * Offset-1 Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Offset-0 projects
   * Voters: PTLs of Offset-0 projects
 * Offset-2 Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Offset-0 projects
   * Voters: PTLs of Offset-0 projects
 * Platinum Members
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: Representatives of Platinum Members
   * Voters: Representatives of Platinum Members

For purposes of avoiding dominance from a particular company, also define any given company as an Represented Group with no seats (and thus no need to define voters):

 for company_var in <the set of all companies>:
   * Represented Group company_var
     * Min Seats: 0
     * Max Seats: 33%
     * Candidates: Works for company_var
     * Voters: None

 Total seats: 12

=== All Types, Mature Lifecycle States ===

This is similar to [https://lists.opendaylight.org/pipermail/tsc/2015-November/004226.html Option 0], which [https://lists.opendaylight.org/pipermail/tsc/2015-November/004230.html seemed to get a fair amount of consensus].

For purposes of avoiding domination by any particular RG, Max Seats is uniformly set to 33% for all RGs except Committers-at-Large (since any TSC member elected will be a committer).

 * Committers-at-Large
   * Min Seats: 5
   * Max Seats: 100%
   * Candidates: Committers to ODL projects
   * Voters: Committers to ODL projects
 * Core Project PTLs
   * Min Seats: 0 (we have no core projects)
   * Max Seats: 33%
   * Candidates: PTLs of Core projects
   * Voters: PTLs of Core projects
 * Mature Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Mature projects
   * Voters: PTLs of Mature projects
 * Kernel Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Kernel-type projects
   * Voters: PTLs of Kernel projects
 * Protocol Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Protocol-type projects
   * Voters: PTLs of Protocol projects
 * App Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of App-type projects
   * Voters: PTLs of App projects
 * Support Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Support-type projects
   * Voters: PTLs of Support projects

For purposes of avoiding dominance from a particular company, also define any given company as an Represented Group with no seats (and thus no need to define voters):

 for company_var in <the set of all companies>:
   * Represented Group company_var
     * Min Seats: 0
     * Max Seats: 33%
     * Candidates: Works for company_var
     * Voters: None

 Total seats: 15

=== All Types, All Lifecycle States ===
For purposes of avoiding domination by any particular RG, Max Seats is uniformly set to 33% for all RGs except Committers-at-Large (since any TSC member elected will be a committer).

 * Committers-at-Large
   * Min Seats: 4
   * Max Seats: 100%
   * Candidates: Committers to ODL projects
   * Voters: Committers to ODL projects
 * Core Project PTLs
   * Min Seats: 0 (we have no core projects)
   * Max Seats: 33%
   * Candidates: PTLs of Core projects
   * Voters: PTLs of Core projects
 * Mature Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Mature projects
   * Voters: PTLs of Mature projects
 * Incubation Project PTLs
   * Min Seats: 1
   * Max Seats: 33%
   * Candidates: PTLs of Incubation projects
   * Voters: PTLs of Incubation projects
 * Kernel Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Kernel-type projects
   * Voters: PTLs of Kernel projects
 * Protocol Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Protocol-type projects
   * Voters: PTLs of Protocol projects
 * App Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of App-type projects
   * Voters: PTLs of App projects
 * Support Project PTLs
   * Min Seats: 2
   * Max Seats: 33%
   * Candidates: PTLs of Support-type projects
   * Voters: PTLs of Support projects

For purposes of avoiding dominance from a particular company, also define any given company as an Represented Group with no seats (and thus no need to define voters):

 for company_var in <the set of all companies>:
   * Represented Group company_var
     * Min Seats: 0
     * Max Seats: 33%
     * Candidates: Works for company_var
     * Voters: None

 Total seats: 15

=== All Types ===
For purposes of avoiding domination by any particular RG, Max Seats is uniformly set to 33% for all RGs except Committers-at-Large (since any TSC member elected will be a committer).

 * Committers-at-Large
   * Min Seats: 3
   * Max Seats: 100%
   * Candidates: Committers to ODL projects
   * Voters: Committers to ODL projects
 * Kernel Project PTLs
   * Min Seats: 3
   * Max Seats: 33%
   * Candidates: PTLs of Kernel-type projects
   * Voters: PTLs of Kernel projects
 * Protocol Project PTLs
   * Min Seats: 3
   * Max Seats: 33%
   * Candidates: PTLs of Protocol-type projects
   * Voters: PTLs of Protocol projects
 * App Project PTLs
   * Min Seats: 3
   * Max Seats: 33%
   * Candidates: PTLs of App-type projects
   * Voters: PTLs of App projects
 * Support Project PTLs
   * Min Seats: 3
   * Max Seats: 33%
   * Candidates: PTLs of Support-type projects
   * Voters: PTLs of Support projects

For purposes of avoiding dominance from a particular company, also define any given company as an Represented Group with no seats (and thus no need to define voters):

 for company_var in <the set of all companies>:
   * Represented Group company_var
     * Min Seats: 0
     * Max Seats: 33%
     * Candidates: Works for company_var
     * Voters: None

 Total seats: 15