Table of Contents maxLevel 3 exclude Updated
Updated by vote of the TSC.
Overview
This page is the result of the community's effort to refactor the OpenDaylight Technical Steering Committee (TSC) election system. It provides background information, guiding principles, a "framework" of ideas that have consensus. OpenDaylight's Technical Steering Committee will be elected by a set of multi-winner elections, one election per 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.
...
TSC elections will happen yearly.
Membership Definitions
- Active Community Members: Anyone from the OpenDaylight community with twenty (20) or more measurable contributions during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, or JIRA activities.
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 ODL Lifecycle states.
...
- Min Seats - Minimum number seats allocated to the RG (as an integer or ratio of total). Provides Representation of Constituencies property.
- Max Seats - Maximum number seats that can be held by the RG (as an integer or ratio of total). Provides Protection from Dominance by a Constituency property.
- Candidates - Set of people eligible to run for the RG's seats. Provides Election by Community Peers.
- Voters - Set of people who can vote in the RG's election. Provides Election by Community Peers.
- Duplicate Voter Strategy - If a person meets the Voter description of this RG for more than one reason, do they get a single vote or a vote for every interest they represent? Resolves Multiple Votes in Same Represented Group corner case (TSC vote)
Election Mechanics
...
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. For RGs with a Vote-per-Interest Duplicate Voter Strategy, voters are given a ballot for each reason they match the RG's Voters description (may require additional email addresses). For RGs with a Vote-per-Person Duplicate Voter Strategy, no voter receives more than one ballot. Voters vote , and the Ranked Preference Algorithm returns the ranked 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 RG is determined. If the actual percentage of TSC seats won by candidates in a Represented Group is higher than the group's Max Seats seat allocation, over-max resolution is handled by a Scaled Popularity Election.
...
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 flexibility over time, allowing the best-known algorithm and tooling to be used for each election. This also allows the algorithm and implementation to be treated like as a black box in the rest of the Election Framework, simplifying user-facing elements by extracting complexity to 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 Condorcet algorithm, with the Condorcet-IRV completion rule, will be used for OpenDaylights OpenDaylight's first new-style election. Tooling will be provided by the Condorcet Internet Voting Service, which is 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.
...
After running the elections for all Represented Groups, for any RG that exceeded the Max Seats seat 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 seat 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 an 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.
...
The result is that person D is eliminated and the main RG elections are re-run.
Represented Groups
TSC Seat Allocations By Represented Group for the 2021 elections
The TSC selected the "All Types + CALOnly Committer-At-Large (CAL)" set of RGs, and 5 seats to the Committers-at-Large RG and 2 seats each to the other 4 type-based RGs, for a total of 13 seats. The TSC also decided that at most 33% 49% of TSC seats be given to employees of a single company and it's affiliated companies, but did not cap other RGs.
...
- Committers-at-Large
...
- Min
...
- Seats:
...
- 3
- Max Seats: 5
- Voters: Committers to ODL projects
- Duplicate Voter Strategy: Vote-per-Person
- Active Community Members
- Min Seats: 0
- Max Seats: 2
- Voters: Active Community Members
- Duplicate Voter Strategy: Vote-per-Person
For purposes of avoiding dominance from a particular company, also define any given company as a 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:
...
- 49% (cap
...
- of
...
- 5)
- Candidates:
...
- Works
...
- for
...
- company_var
...
- Total seats: 2