We have already agreed that the TSC will consist of the following represented groups:
We have talked about having caps on the representation of different groups (as well as companies) to avoid any given group (or company) having too much control of OpenDaylight. In those discussions, there seemed to be consensus that 33% of the TSC (or 4 seats in the upcoming election given that we have 13 seats total) is a good cap.
There was less consensus on how to resolve who should be elected from a given group assuming that group hit a cap. This vote is to decide how we do that.
For additional context, please see the recent activity on the relevant TSC mailing list thread. The conversation leading up to this vote starts with this message in particular.
It might also be useful to review the relevant section of the TSC Elections Proposal wiki page which describes all three alternatives in the exact words as below with some additional justification for each.
Note that the results of this vote will include details about which TSC members voted and how.
| 1. Scaled popularity as described on the TSC Elections Proposal with the person winning the least % of their election being dropped first (Condorcet winner: wins contests with all other choices) |
| 2. First repeatedly remove the lowest ranked candidate in the RG election with the most representatives from the capped group or company that is over it's cap (note that the RG election thus must have 2 or more winning candidates from the same capped group or company) and then use scaled popularity if there is more than one RG election with the most winning candidates from the company or group hitting the cap (note that this might be with only 1 winner per RG election). Additional context on the wiki. loses to Scaled popularity as described on the TSC Elections Proposal with the person winning the least % of their election being dropped first by 5–3 |
| 3. First repeatedly remove the lowest ranked candidate from the company or group hitting the cap in the committer-at-large election, then proceed as in the other approach with repeatedly removing the lowest ranked candidate from the RG with most representatives from the company or group hitting the cap, and finally resolving by scaled popularity if no single such RG election exists. Additional context on the wiki. loses to Scaled popularity as described on the TSC Elections Proposal with the person winning the least % of their election being dropped first by 6–1, loses to First repeatedly remove the lowest ranked candidate in the RG election with the most representatives from the capped group or company that is over it's cap (note that the RG election thus must have 2 or more winning candidates from the same capped group or company) and then use scaled popularity if there is more than one RG election with the most winning candidates from the company or group hitting the cap (note that this might be with only 1 winner per RG election). Additional context on the wiki. by 6–2 |
For simplicity, some details of the poll result are not shown.
| 1 | 2 | 3 | ||
|---|---|---|---|---|
| 1. Scaled popularity as described on the TSC Elections Proposal with the person winning the least % of their election being dropped first | - | 5 | 6 | |
| 2. First repeatedly remove the lowest ranked candidate in the RG election with the most representatives from the capped group or company that is over it's cap (note that the RG election thus must have 2 or more winning candidates from the same capped group or company) and then use scaled popularity if there is more than one RG election with the most winning candidates from the company or group hitting the cap (note that this might be with only 1 winner per RG election). Additional context on the wiki. | 3 | - | 6 | |
| 3. First repeatedly remove the lowest ranked candidate from the company or group hitting the cap in the committer-at-large election, then proceed as in the other approach with repeatedly removing the lowest ranked candidate from the RG with most representatives from the company or group hitting the cap, and finally resolving by scaled popularity if no single such RG election exists. Additional context on the wiki. | 1 | 2 | - |
| Scaled popularity as described on the TSC Elections Proposal with the person winning the least % of their election being dropped first | First repeatedly remove the lowest ranked candidate in the RG election with the most representatives from the capped group or company that is over it's cap (note that the RG election thus must have 2 or more winning candidates from the same capped group or company) and then use scaled popularity if there is more than one RG election with the most winning candidates from the company or group hitting the cap (note that this might be with only 1 winner per RG election). Additional context on the wiki. | First repeatedly remove the lowest ranked candidate from the company or group hitting the cap in the committer-at-large election, then proceed as in the other approach with repeatedly removing the lowest ranked candidate from the RG with most representatives from the company or group hitting the cap, and finally resolving by scaled popularity if no single such RG election exists. Additional context on the wiki. | |
|---|---|---|---|
| vishnoianil@gmail.com: | 2 | 1 | 3 |
| abhijitkoss@gmail.com: | 3 | 1 | 3 |
| dfarrell@redhat.com: | 3 | 1 | 2 |
| adetalhouet@inocybe.com: | 1 | 3 | 2 |
| hagbard@gmail.com: | 1 | 3 | 2 |
| gidi@hpe.com: | 1 | 2 | 3 |
| chrispriceab@gmail.com: | 1 | 2 | 3 |
| colin@colindixon.com: | 1 | 2 | 3 |
Ballots are shown in a randomly generated order.
[Download ballots in CSV format]
Feel like voting on something else? Try one of these public polls: