Latest revision as of 15:42, 14 December 2017

warning - very drafty - these are for discussion and likely have some bad ideas in them

FD.IO TSC ELECTION PROCEDURES

This page describes the proposed TSC selection procedures

Overview

With the changes in the Linux Foundation structures for networking projects, to behooves us as the fd.io TSC to develop a plan for moving from a Platinum Membership based TSC to one based on the contributing community. This page proposes a target operating procedure, and a transition path to move smoothly from our current state to our desired state. It starts by laying out some guiding principles and concerns that drive the choices made herein.

Principles

The following are a short list of principles that drive the election procedures. These principles are sometimes in conflict with each other, and balancing such is a judgment made by the TSC, not a matter of mathematics of formal correctness.

Represent the Implementing Community

The membership in the TSC should be made up of folks who understand and represent the interests and concerns of the people actually building the system. While input from users is always important, the project is driven by those who contribute.

Attention to Central Concerns

Certain aspects of the FD.IO project are central to the overall project. When issues from these aspects are not given due attention, the likelihood is high that there will be side-effects throughout the project. Thus, these aspects need to be directly represented on the TSC.

Avoidance of Central Dominance

While certain technical aspects are critical, and at times certain companies provide significant resources to the project, the TSC election structure needs to ensure that the TSC represents broader concerns and can not be captured by or subservient to any specific interests.

Modern Election procedures

Given that we are selecting a multi-member TSC, it is important that we use election procedures that have been found to cope with this task with some robustness and reasonable fairness (putting aside the proof that no election procedure is ever perfect). While the procedures below make a specific choice, the principle is that techniques like Condorcet or Single Transferable Vote be used.

Flexibility

It is not expected that these procedures are perfect, nor necessarily suited to changes that may occur in the project over time. As such, the TSC is expected to use judgment in applying these procedures, and to update them as needed. It is important that the adopted procedures in current effect be easily identifiable and findable by any interested parties. For example, if the number of Core projects changes drastically, then the core related procedures below will likely need revision.

Orderly Transition

Whenever major changes are made to these procedures, the TSC should keep in mind the need for an orderly transition from what is current to what is desired procedurally.

Procedures

The following subsections lay out the agreed desired procedure, to be in place following the transition process, for selecting the FD.IO TSC

Frequency

TSC Elections shall occur yearly (the exact timing and logistics for this are to be determined).

Membership

The TSC Shall consist of 1 representative from each core project, and 3 representatives from the remaining project pool voting collectively. [editor's note: There was some discussion of requiring that the core TSC representatives be the PTLs. I have opted for a more flexible first cut.]

No person may hold more than one seat on the TSC. No Company may hold more than 2 seats on the TSC.

Election Procedure

For the core projects, the representative shall be a committer for the project, elected as describe in the next section by the pool of electors made up of the project commiters. The remaining representatives shall be commiters from any of the non-core projects, elected by the pool of commiters for all of the non-core projects.

Editors question: From Ray, what about maintainers?

For each pool (each core project, and the collection of non-core projects) a call will be put out for self-nomination, allowing a suitable period for nominations. This suitable period will be at least two weeks, and may be longer at the discretion of the TSC. the TSC will also appoint, with the help of the Linux Foundation, suitable neutral parties to manage the election.

Once the nominations have been submitted, the elections will be conducted. Ballots will be distributed, and the election conducted using the Condorcet Algorithm as supported by the Condorcet Internet Voting Service. Subject to two special concerns, the winner or winers (depending upon the number of seats to be elected) will be deemed to have been elected.

Caveat 1: A person may not hold more than one seat at a time. If, for example due to overlapping elections, the same individual wins for more than one seat, that individual may choose which seat s/he takes, and the next candidate in the condorcet ordering will take any other seat for which the individual has won but is not taking. In the event that there are now insufficient candidates for such a seat, another round of self-nominations and election will be held.

editor's note: It has been suggested that a better answer might be to require tha an individual only stand for a single seat in a given election. That would be simple.

Caveat 2: No company may hold more than 2 seats on the TSC. In the event that a single Company wins election for 3 or more seats on the TSC, the selected individuals from that company will decide among themselves which two will keep their seats, and the third (or more) will turn down selection. The condorcet selected candidate following individuals who are declining election will be selected. Note that any candidate from a company that has filled its TSC seat capacity will also be skipped. In the unlikely event that this produces another company with more than 2 seats, this procedure will be repeated as needed. As with Caveat 1, if there are no available candidates remaining, a new round of self-nomination and election will be held.

editor's note: It is possible that this company procedure will create a vacancy in some seat that had not been up for election. Do we go back to the old election to find the next candidate? Do we hold an "immediate" election for that seat"?

Transition

The transition plan suggests two transition stages, one simple, and to be done as soon as possible, and one intended to bring us close to the targeted process while preserving continuity.

Stage 1

The first, and simplest step is to promote the CSIT project to be core. This will add another member (The CSIT) PTL to the TSC immediately. This need not wait on the agreement on the rest of the procedures.

Stage 2

Once the rest of the procedures are agreed by the TSC, then the TSC shall hold an election to add the requisite number (3) of representatives from the committers of the non-core project to the TSC. The TSC shall also select a time line for conducting that election, seating those members, and reviewing the plan.

Stage 3

At a time determined by the TSC during stage 2, but no later than January 1, 2018, the TSC membership shall transition to being made up by the elected representatives. This will require an election from the core projects (for which the PTLs may, and it is hoped will, stand). The TSC shall decide whether a second election for non-core project representation is needed as part of completing this transition.

Open Issues

Should we saying anything about proxies? Our current practice is that no one person may have more than one vote, and that TSC members may nominate proxies as needed from outside the TSC to cover when they can not make the meetings. Other open source projects allow a person to hold several proxies to better cope with time differences.

We should have text about filling openings, e.g. for when a TSC member resigns.