community/elections/steering/documentation

Steering Election HOWTO

This documentation explains how to run a steering election. As a work in progress, it replaces older documentation where present; for topics not covered consult the older documents in each election folder.

Documentation contents

• This guide, which covers all process and roles.
• A folder of templates, primarily for election-related communications
• Current SQL query or devstats report for selecting voters

Roles

The Elections Subproject

Members of the Elections Subproject have three responsibilities around steering elections:

1. Recommending Election Officers to the Steering Committee
2. Intervening if anything unexpected happens with the EOs
3. Following up on recommendations from the election retro

The Election Officers

The Election Officers (EO) are three trusted contributors who will run one or two Steering elections. They are responsible for making sure that the election happens and completes satisfactorily.

Election Officers must meet the following requirements:

• Org member for more than one year
• Eligible to vote in the election
• Pledge to administer the election without partiality to any employer, SIG, or personal preference
• Tentatively available for two elections in a row (see below)
• Tentatively available for special elections in the upcoming year (see below)

Additionally, the Elections Subproject will choose Election Officers partly to respresent the diversity of Kubernetes contributors, selecting different genders, geographic regions, and ethnicities where possible, in order to avoid the appearance of bias in the elections process. Particularly, the three Officers must each work for a different employer.

Election Officers are responsible for:

• Planning the election, including creating a draft timeline
• Generating the voter list
• Setting up the election in the voting system
• Deciding on exception requests
• Determining candidate eligibility
• Assisting candidates with bios
• Publicizing the election in order to maximize participation
• Finalizing and reporting the election results
• Hosting an election retro & documenting changes
• Contributing to the SC election documentation

These responsibilities are detailed in the election procedures. They collectively fall in to four main areas, timewise:

1. Communications with candidates and voters (together with the Comms Liaison)
2. Administering the election software (together with the Infra Liaison)
3. Managing nominations and candidates
4. Responding to exception requests

Usually, the three Election Officers divide up the above major responsibilities among the team, each Officer taking one or two of them.

Each year, at least one Election Officer must be a prior Officer in order to ensure continuity of knowledge. As such, Officers should be theoretically available to do the elections two years in a row. Further, should a special election become necessary because of the resignation of an SC member mid-year, this year's Officers are responsible for running the special election, so any Officers should be at least tentatively available for that.

Alternate Election Officer

In addition to the three Officers, the Elections Subproject will recommend one or two Alternate(s). This Alternate is available in case one of the Officers is unable to complete the election, or is unavailable for post-election duties (such as a special election). Any current Officer may activate the Alternate if any Officer resigns or is unavailable.

The Alternate(s) will be added to the Election Officers slack and email alias, but will have no specific duties and will not participate in votes unless activated. Alternate(s) are also intended to be in training to run the following year's election.

K8s Infra Liaison

Currently election software runs on the Kubernetes cluster owned by the k8s-infra team. As such, the Election Officers may need troubleshooting and support from k8s-infra in case of unexpected problems with the Elekto deployment or changes needed to the software.

As such, before the election starts, the Officers should reach out to k8s-infra team and request one person who will be available to assist. This person should be available during most of the election period. They must have the ability to approve/modify services running on k8s.io.

If one of the Officers has these permissions, they may also serve in this role.

Contributor-Comms Liaison

A big part of the election effort is making sure that voters and candidates are aware of the election and kept up to date with constant reminders. As such, the Officers work directly with Contributor-Comms to send out a stream of messages to the community.

Well before the election starts, the Officers should reach out to contributor-comms and ask them to assign one team member to handle election communications.
This Comms member needs to have the ability to approve tweets.

If one of the Officers is a member of Contributor-Comms, they may double up in this role.

Timeline and Processes

What follows is a timeline for conducting the steering committee election. Since the actual calendar varies a bit, time below will be expressed starting at "day 0," which is usually sometime between June 1 and June 30. Figure out your calendar offsets based on that, and copy this grid to document the current election.

Most of the days below have quite a bit of adjustment room; there's just a few where things must happen in a specific number of days.

Day	Activity	Roles	Notes
0	Begin EO Selection	Subproject Leads
10	Nominate EO members	Subproject Leads
14	Approve EO members	Steering Committee
20	Select liaisons	EO Members
20	Propose timeline	EO Members	Also, propose any eligibility changes
24	Update Elekto	Infra Liaison	Make sure that Elekto is up to date
25	Approve Timeline	Steering Committee
26	Request Voters	EO Admin	request list from Devstats
26	Create Retro doc	EO Members	Open this early for notes
28	Prepare Comms Plan	EO Comms
30	Create Election Config	EO Admin	Create the election in k/community
32	Open nominations	EO Members	Announce start of nominations
32-51	Validate Candidates	EO Nominations	Continue through period
32-78	Evaluate Exception Requests	EO Members	All the way through election
43	1st Nominations Reminder	EO Comms
45	Candidate/SC Q&A	EO, SC, Candidates	Any time during nominations
48	2nd Nominations Reminder	EO Comms
49	Last Nominations Reminder	EO Comms
50	Nominations Close	EO Members
51	Clean Up Nominations	EO Admin	Fix/Edit Candidate statments
53	Announce Voting	EO Comms	k/dev, LWKD, Slack
55	Voting Blog Post	EO Comms
60	First Voting Reminder	EO Comms
67	Second Voting Reminder	EO Comms
74	Third Voting Reminder	EO Comms	remind that exceptions close
78	Close Exceptions	Automatic
80	Final Voting Reminder	EO Comms
81	Election Closes	Automatic
82	Send Results to SC	EO Admin
84	Approve Results	Steering Committee
86	Inform Candidates	EO Member	MUST BE 24-48 hours before announcing
87	Announce Results	EO Comms	on K/dev, etc.
88	Election Blog Post	EO Comms
89	Results in Elekto	EO Admin
94	Upload ballots.csv	EO Admin	Also detailed results
95	Hold Retro	EO, Subproject	Anytime within 2 weeks

Election Officer Selection

At the beginning of the election cycle, ideally in Early June, the Elections Subproject Leads will select Election Officer candidates.

Potential sources for qualified EO candidates include:

• Previous EO members
• Emeritus Steering Committee members
• Current Steering members who are terming out
• Current or former Contributor Experience leads
• Other current or former Kubernetes team leaders

Subproject leads will choose the EOs to match the criteria for the role. The Subproject is not required to issue a public call for candidates, nor document their EO selection process, unless asked to do so by the Steering Committee.

When they settle on a final list of three candidates and one or two alternates, they will check in with SIG-ContribEx leads, and then propose the list of officers to the current Steering Committee. This proposal should happen as an issue or PR, such that all Steering members are able to see the proposal and comment on it. If Steering requires different candidates, the Subproject Leads will find alternate EO possibilities until Steering approves.

A Subproject lead will submit a PR to create the team, primarily creating an OWNERS file in the appropriate steering/YEAR directory. The Subproject lead will also be responsible for ensuring that the new EOs are set up both on Slack and email. Setting up the officers at the election@kubernetes.io alias is done by submitting a PR against the groups file.

To set up the officers on Slack, the lead will request that a continuing EO invite them to the #election-officers channel. They will then update the membership of the channel to include all current Officers and Alternates.
The Subproject lead will then stay on the channel to assist and answer questions until the new EOs submit a schedule proposal to Steering. At that point, the Subproject lead will leave the channel.

Set Up

Creating The Election Team

Once the three EOs and an alternate have been selected, they should find liaisons. This means requesting a Comms liaison from Contributor-Comms, and an Infra liaison from SIG-K8s-Infra. It's possible that both of these roles exist among the EOs themselves, in which case Liaisons do not need to be selected.

Then the EOs should decide among themselves who will be taking on which duties.

Hereafter, we will refer to the various roles with these abbreviations:

• EO Comms: the EO member taking on comms duties plus the Comms Liaison
• EO Admin: the EO member taking on Elekto admin duties
• EO Nominations: the EO member taking on nomination/candidate wrangling
• EO Voters: the EO member in charge of voters.yaml and exception requests
• Infra: the Infra Liaison

Create a Timeline

The second thing the EOs need to do is to create a timeline with specific dates for each of the election activities. While this will be based on the default timeline above (or in the template README), EOs will have to adjust this for the realities of the current year. If the election cycle started late, they may need to shorten some periods. EOs should keep some limitations in mind for scheduling:

• Don't have any deadlines fall during, or immediately after, a Kubecon week
• The Nominations period must be at least 2 weeks
• The Voting period must be at least 2 weeks, and should be three
• 1-2 day gaps between some steps exist in case of problems (e.g. Elekto error, Steering unresponsive)

Once EOs have a draft timeline, they will submit it to Steering to approve, either as an issue in k/steering, or as a PR that creates the README for the election. Asking for review on Slack is recommended. Once a majority of Steering members have approved, the timeline is final.

Note that any consequential changes to the timeline (such as changing close dates or the results date) require re-approval by Steering.

At the same time you have Steering approve the timeline, they should also approve the voting eligibility criteria. As such, you should propose using the same criteria as last year; Steering will make any changes that they need to.

Requesting Voters

The eligible voters list is produced through this process:

1. Generate the list of eligible contributors from Devstats, filtering by required number of contributions. Search for all repos for the last year, bots excluded, and generate a CSV to download.
2. Match this list against the list of Org members supplied from the Org Repo, discarding any contributor who is not an Org member. An example of how to produce the Org member list:

yq '.admins + .members'   config/kubernetes/org.yaml   config/kubernetes-client/org.yaml   config/kubernetes-csi/org.yaml   config/kubernetes-sigs/org.yaml | sort -f | uniq | grep -v "\-\-\-"

3. Add to the list all members of the Code of Conduct Committee and Security Response Committee, if not already present

4. Sort alphabetically, deduplicate if required, and reformat to match the format of voters.yaml template

Note that currently Elekto is case-sensitive and requires capitalization in voters.yaml to match the official capitalization of each contributor's GitHub account. While this may be fixed in the future, you need to be careful to preserve capitalization when copying GH IDs for now.

Creating The Election

For Steering elections, we are currently using Elekto. Elekto is a GitOps system. Thus, creating the election is a matter of copying the template files over from templates/files, and filling in the details per the current election. Here's some brief notes on the contents of each file:

• README.md: This is the human-readable complete set of election instructions. It should contain general information about the election, a timeline, eligibility requirements, etc. It is not displayed in Elekto.
• election.yaml: this is the configuration file that defines the election for Elekto. All of the missing information here needs to be filled in. This file will need to be renamed from election-template.yaml to election.yaml
• election_desc.md: this is human-readable brief summary of the election, displayed to voters by Elekto.
• voters.yaml: this is the list of eligible voters used by Elekto.
• nomination-template.md: this is a sample candidate template for candidates to base their nomintation statements and profiles on. You should not need to edit it.

Each of the above templates will have blanks to fill in. When the EO Admin has filled in all information, they submit it for the other two EOs to approve. Ideally, a project member trained on Elekto will also review it for technical errors.

Once the file is merged, the election should appear on the election website in half an hour or less. If it does not, contact the Infra liaison for troubleshooting.

Updating Links

The last set of PRs for setting up the election is to update links and other files. That includes:

• Update steering election README to point to the current election
• Update the elections doc in the Steering repo with the current EOs
• Update the elections alias to direct to the current EOs

Create a Comms Plan and Messages

The timeline above has a lot of messages and posts that go out as election publicity and reminders. To keep on top of this, the EOs should prepare a Comms Plan that includes the planned dates of all announcements, with draft text for each of these messages. This document allows election communications to be complete and on schedule, even if the Alternate needs to pick it up.

Templates for some of the expected messages that EO Comms sends out can be found in the messaging folder, to be updated for the current year and sent out. Where templates are not available, search the k/dev archives for prior years' examples, or prior years' comms plans. And then please create a template and put it in the messaging folder.

Aside from specifically targeted messages, there's two levels of messages to be sent out:

• Major announcements: opening of nominations, start of voting, election results
• Reminders: many other reminders during the election cycle

Reminders are sent to k/dev and #announce and #kubernetes-contributors slack channels, and sometimes to social media at the discretion of EO Comms.

Major announcements are sent to those places, definitely to social media, and also broadcast via the slack bot to all SIG channels. They should also be posted via LWKD, shared in the SIG Leads meeting, and posted as a short blog post in the contributor blog.

Steering Committee Supervision

Some things for the election need to be decided by Steering. Approving the EOs, approving the timeline, and any voting or candidate eligibility adjustments, are decided by all of Steering. Steering decisions that need to be made during the election, such as approving the final results, are approved by "non-involved Steering members." This consists of the group of Steering Committee members who are not running in the current election.

Nominations Phase

Two to three weeks before voting starts, you should open the election to nominations. The actual nominations process is described in the election README, so this guide will focus on what the EOs need to do.

First, EO Comms needs to announce the start of nominations, which is a major announcement. This announcement also includes the call for Voter Exceptions.

Candidate Nominations

Once nominations have started, the EOs have basically three duties to candidates:

1. Reminding folks that they need to run via broadcast announcements
2. Helping candidates/nominators with nominations
3. Helping candidates with their profile PRs and debugging errors
4. Verifying candidate eligibility

The EOs are responsible to make sure that everyone who might be thinking about running for SC knows that an election has started, and is aware of the deadlines. The way to do this is announcements in all the community places. EOs should not do 1-on-1 private outreach to potential candidates, because this could be interpreted as partisanship. EOs can and should reach out to already declared candidates privately to help them create and format their candidate statements.

A candidate declares themselves by filing an Issue in the [Community repo], and linking that issue with an announcement on k/dev. Occasionally, someone other than the candidate will do that nomination, but mostly it's self-nominations.

Importantly, voters are not to endorse the candidate on k/dev itself; all endorsements must be made on the issue. This will be one thing EOs have to fix, probably more than once. If a thread starts with people +1ing the candidate via email on k/dev, post an announcement saying something like

We remind you, as Election Officers, that your fellow contributors have asked you NOT to make endorsements on the mailing list.  Further, endorsements on the mailing list do not count towards candidate eligibility.  Instead, endorse this candidate here: <LINK to ISSUE>

In severe cases, EOs may need to ask the k/dev admins to lock the thread.

On the rare occasions that a voter nominates the candidate instead of themselves, an EO should reach out to the candidate to make sure they accept the nomination.

When a candidate creates an issue, EOs should check if they've copied in the process for endorsements; if not, an EO should. Particularly, voters need to remember to provide their employer name. Then the EO Nominations watches to see when the candidate accumulates the necessary three endorsements from contributors working for different employers. At that point, EO Nominations posts to the issue:

<CANDIDATE NAME> has the necessary endorsements and is eligible to run in the Steering Committee election.  The candidate should prepare their candidate profile as a PR and submit it, per the instructions at: https://github.com/kubernetes/community/blob/master/elections/steering/{{YEAR}}/README.md#candidacy-process

In most cases, there are no other eligibility requirements. Candidates are not required to be documented contributors or org members. The Issue will remain open until the candidate profile is merged as a PR.

Candidate Profiles

Candidate profile files are required for the candidate to be electable in Elekto. They also give the community some idea who the candidate is and what they advocate. Since these profiles are both a technical document (Elekto expects certain data and headers), and a platform document, some candidates will need help preparing them. Here's the main areas where EOs help:

File Names: the correct name for each candidate profile is candidate-ghid.md where the second part is the GitHub ID of the candidate. This ID must exactly match the ID field inside the file itself.

Header Formatting: the file is a markdown file with a YAML header. Candidates often mess up the YAML header. Things that will break it include: deleting or renaming fields, using the @ symbol, removing the -------- break for the header delimiter, or changing the indenting. Check for, and correct, these things.

Candidate Statements: Some candidates may need editorial help on the contents of their candidate statements. This can range from spelling, punctuation, and markdown correction, to help making their ideas and self-description clear. There is also a loose limit of 300 words for the candidate statement, so EO Nominations will block merging any candidate statements that are excessively long until the candidate edits them.

Once candidate profiles are fully corrected, they can be merged to be ready for the election. There should be a 2-3 day grace period between the close of nominations and the start of voting to do any last-minute cleanup.

Candidates who miss the nomination deadline, or who are unresponsive to needed corrections past the beginning of voting, are ineligible to run.

Voter Exceptions

Devstats activity doesn't capture 100% of contributions, so through the whole voting cycle the EOs will be approving requests for Voting Exceptions. These exceptions allow folks to vote who didn't show up in the original voters.yaml file.

Voters can check their eligibility in Elekto, which shows them whether it thinks they can vote. They can also check the file. If a voter is not eligible but thinks they should be, they file an Exception via a link in Elekto. These exception requests will display as a list in the election admin page, along with a toggle for whether or not the EOs have evaluated the exception request.

The EOs should stay on top of these exception requests, ideally telling the person within a few days whether they are eligible or not. The EOs discuss and vote on exceptions. Generally, the endorsement of two EOs is sufficient to approve an exception, although it's important that all three EOs can see the discussion.

Once a decision has been reached, the EO Voters will email the person with the decision. Since Elekto does not maintain results of decisions (just that they've been evaluated), or email anyone, this needs to be handled separately by the EOs.

All else being equal, the EOs should err on the side of approving rather than rejecting exception requests. Voter turnout is a challenge with every election, and exception requestors almost always vote. However, there are some precedents:

Eligible:

• Contributors with over 50 contributions who aren't org members, but file an exception. In this case, urge them to become org members as well as granting it.
• Contributors whose org membership has been filed but is not yet approved
• People who have assisted extensively (as in, 15+ hours work) with the Kubernetes Contributor Summit
• Anyone who appears in SIGs.yaml for a role that they are currently fulfilling (not Emeritus, and not for deprecated subprojects)
• Members of a Release Team in the last year

Ineligible without other contributions:

• Writer/maintainers of 3rd party information resources (private/company blogs, personal/company Kubernetes websites, personal video channels)
• Meetup organizers
• Conference speakers
• Contributors to other CNCF projects
• Contributors to Kubernetes distributions

These are precedents, though, and the EOs will need to use their judgment on whether or not the individual's activity represents a significant contribution to the Kubernetes project in the last year.

People should be able to request voter exceptions until 3 days or so before the end of voting. Once voting has started, the EOs should notify requestors more quickly.

After the election, the EOs will report to Steering how many requests were received, and how many granted or denied. EOs do not report on any specific exception request. To avoid embarrassment, particularly for people whose requests were denied, the details of exception requests are treated as confidential.

Steering/Candidates Meeting

The project tries to arrange a private Q&A session where the candidates can meet current Steering members and ask about the position. Given time zones, this often means two meetings. These sessions should be near the end of the Nominations phase, but are sometimes held at the beginning of voting.

The way to set this up is:

1. File a ticket in Steering, and ping the SC over slack to set up a time or times
2. Remind the SC until you have 1 or 2 sessions scheduled
3. Invite all candidates then announced to the sessions

Voting Phase

The Voting Phase is the actual "election", and is the time between the election dates in Elekto. During this phase, the EOs primary job is promoting voter turnout. Historically, Steering elections have had around 1/3 participation, and go down slightly each year. As such, the key activity during this phase is the various announcements.

Initial Voting Announcement

For attention, EO Comms wants to make the opening of voting as grand as possible. This would include all of the standard methods above. Also, Comms should consider a blog post on the Contributor Blog that lists all the candidates and their bios.

Reminders

You'll see from the sample calendar that there are many reminders during voting. These may seem excessive but they are completely necessary.

One additional reminder option is to send one email reminder to voters. The email script will pull email addresses for most (but not all) voters.

Candidate Campaigning

Kubernetes has a policy against "excessive campaigning", which in practice means that the candidate is not supposed to promote their own candidacy beyond simple statements that they are running. Further, they should not use any privileged access to large groups (such as specific SIGs, events, or their coworkers) to encourage votes. Judgements on this can be fairly fine-tuned; for example, Steering has previously ruled that a candidate may send an email to their coworkers reminding them of the election, but that email may not contain information on them as a candidate.

Should a candidate violate this, report it to Steering, who will decide what action is warranted.

As much as the EOs have time, then, they should attempt to make sure that the entire community has good information about all candidates, even beyond what's in the app. One idea (not yet tried) would be to have panel discussions with the candidates on video. The challenge is that all candidates would need to be included in at least one panel, making logistics difficult.

Determining Results

After all of the reminders, the election concludes automatically once past the election close date. Any extension of that date would need to be approved by Steering.

Once the election is closed, on the Admin screen you will see a Generate Results option which will allow you to see who "won". This is a pure Condorcet ranking, and ideally the EOs will select the top # of winners, depending on how many seats are open. However, proportional representation can interfere with that.

After selecting the initial list of winners, count the number of Steering members working for each employer that would be in the new SC. If more than two members would share the same employer, then any newly elected candidates from that employer drop out of the winners list, and choices move one down. In the as-yet-unprecedented event that a candidate was disqualified from the race due to excessive campaigning or CoC violations, then remove that candidate from the winners list.

If removal happens, all three EOs need to discuss and achieve consensus on the removal. If no removal is happening, any one EO can report the results.

The remaining "top #" winners are the new Steering members.

Notifying the Community

Notifications of the results happen in the following order:

1. Notify non-involved Steering
2. Notify the candidates themselves
3. Announce to the community
4. Update results.md
5. Publish blog post

The first step is to contact the non-involved Steering members. Steering will approve the election results as reported by the EOs. This communication will also share the complete ranking of all candidates, how many exceptions were requested and how many granted, and whether proportional representation limits affected the result.

Secondly, the EOs should notify the candidates themselves. This should happen about 24 hours before the election is officially announced, in a communication that tells the candidates to keep the results to themselves.

Then the results are announced to the community. Sometimes this happens via an event. In the past, it was at the Community Meeting. A couple of other times, Steering announced the results at an SC meeting. Other times, though, the announcement has been strictly online. Even if there is an event, EO Comms will work with a designated Steering member to announce the results via k/dev and the slack channels.

After the announcement, an EO will compose a brief version of a results.md file and merge it in so that the results display in Elekto. Until this is done, voters using the app cannot see the results.

Finally, the EOs with Steering will publish a blog post to the Kubernetes blog announcing the new Steering committee and thanking departing members for their service.

Post Election

Once the election is concluded, the EOs have a bit of cleanup.

Upload Ballots.csv

Within a week after the election, one EO should download the anonymized ballots from Elekto and check-in the ballots.csv file to the appropriate election folder. This allows the election results to be checked, and the election database to be recreated, at any time in the future.

Retro

Within 2 weeks of the election, the EOs should hold a retro meeting (2022 retro) for the election. The Retro doc should have been opened near the beginning of the election cycle (see schedule above), allowing the EOs to note issues and successful ideas as they happen. Right after the election closes, they should annotate any additional thoughts and then schedule a meeting that all EOs and shadows can attend.

In addition to the EOs, the following folks should be invited to the retro, but are optional:

• Members of the Election Subproject
• Steering Committee members (both old and new)

Once the retro meeting has been held and the doc is complete, it should be copied as a markdown file into that year's election folder for future reference.

Special Elections

While it has not happened to date, Kubernetes' bylaws provide for a special election to be held during the year if too many members resign from the SC at once, or if a special election is triggered by someone being dismissed from the SC by a vote of the committee, or if the SC is dissolved by vote. In any of these cases, the EOs from the last prior steering election are expected to administer this special election. If some EOs are unavailable (due to absence or running in the special election), then the Alternate(s) will serve. If there still aren't enough EOs, the Elections Subproject members will chose one or more emergency EOs from the Subproject members or from the list of prior EOs.

These Special Elections will be held on a shorter schedule than the regular election, if possible. The EOs should organize and announce the election as quickly as possible, and consider reducing the nomination and voting phases to two weeks each instead of three.

Additional Notes on Being an EO

Impartiality

A key part of making Kubernetes elections work is trust in the impartiality of the system. Election Officers, and Alternates, should be careful to avoid any activities that would make them appear biased towards one or more candidates. In particular, EOs are discouraged from:

• Endorsing or criticizing particular candidates, either in Kubernetes areas or on social media
• Giving any candidate special assistance that is not offered to other candidates
• Promoting any candidate at the EO's workplace or in other external organizations
• Posting personal opinions on the election that do not represent the consensus of the EOs
• Taking on multiple EO roles such that the other EOs cannot check their work

EOs Dropping Out

EOs may not be able to complete the election for a variety of reasons, including illness, personal conflicts, or an inability to remain impartial. In any of these cases, the EO should notify their fellow EOs, and the Alternate will be promoted to take their places. If any EO is unexpectedly unresponsive for several days in a row, the other EOs may decide they are inactive and promote the Alternate. In either case, they should notify the Subproject and Steering of the change and the reason for it immediately.

Should more than one EO drop out, leaving less than three EOs, then the remaining EO(s) should contact the Election Subproject to recruit/appoint new EOs as soon as possible. In most cases, this will also require delaying the election schedule.