...
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.
...
- 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.
...
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.
...