Knative steering committee

The Knative Steering Committee (KSC) is responsible for the general health of the Knative community.

The governance of Knative is an open, living document, and will continue to evolve as the community and project change.

Charter

  1. Define, evolve, and promote the vision, values, and mission of the project.
  2. Define and evolve project governance structures and policies, including project roles and how collaborators become members, approvers, leads, and/or administrators. This includes policy for the creation and administration of working groups and committees.
  3. Steward, control access, delegate access, and establish processes regarding all Knative project resources and has the final say in the disposition of those resources.
  4. Advise the Trademark Committee on usage of the brand and marks in relation to promoting the community. This advice is non-binding on the Trademark Committee.
  5. Define and evolve the scope of the Knative community and extensions, and the process for migration of sandbox projects into Knative Extensions.
  6. Receive and handle reports about code of conduct violations and maintain confidentiality.
  7. Receive security reports; work with the appropriate technical leads to accept or reject the report; maintain the private nature of such reports until disclosed to the broader community.
  8. Act as the final escalation point and decider for any disputes, issues, clarifications, or escalations within the project scope.

Delegated authority

KSC may choose to delegate its authority to other committees as-needed. The committee currently recognizes this delegated authority for:

Committee Meetings

KSC meets every two weeks, or as-needed. Meetings are held online.

Given the private nature of some of these discussions (e.g. privacy, private emails to the committee, code of conduct violations, escalations, disputes between members, security reports, etc.) some meetings are held in private.

Meeting notes are available to members of the knative-dev mailing list (note: these are accessible to members of the knative-users list as well). Public meetings will be recorded and the recordings made available publicly.

Questions and proposals for changes to governance are posted as issues in the community repo, and the KSC invites your feedback there. See Getting in touch for other options.

Committee members

Seats on the Steering Committee are held by an individual, not by their employer.

The current membership of the committee is currently (listed alphabetically by first name):

  Member Organization Profile
Alex Nicolaou Google @anicolao
April Kyle Nassi Google @thisisnotapril
Brenda Chan VMware @bsnchan
Michael Behrendt IBM @mbehrendt
Paul Morie Red Hat @pmorie
Ron Avnur Google @ronavn
Open * Google

* Open seats have been allocated to the organization per the prior committee rules, but have not been assigned to a member of the organization or replaced with elected seats.

Decision process

The steering committee desires to always reach consensus.

Decisions requiring a vote include: issuing written policy, amending existing written policy, creating, removing, or modifying a working group, all spending, hiring, and contracting, official responses to publicly raised issues, or any other decisions that at least half the members present decide require a vote

Decisions are made in meetings when a quorum of the members are present and may pass with at least half the members of the committee supporting it.

Quorum is considered reached when at least half of the members are present.

Getting in touch

There are two ways to raise issues to the steering committee for decision:

  1. Emailing the steering committee at knative-steering@googlegroups.com. This is a private discussion list to which all members of the committee have access.
  2. Open an issue on a knative repository and indicate that you would like attention from the steering committee.

Composition

The steering committee has 5 seats. These five seats are Contributing seats, open to any project contributor. In the future, the steering committe would like to add two End-User seats, open only to active end-user community members, once the selection criteria have been established. See candidate eligibility for definitions of these categories.

Steering Committee members serve for 2-year terms, staggered in order to preserve continuity. Every year either two or three contributor seats are elected. Once end-user mechanics are established, one end user seat would be elected on the same schedule.

Election Procedure

Timeline

Steering Committee elections are held annually. Six weeks or more before the election, the Steering Committee will appoint Election Officer(s) (see below). Four weeks or more before the election, the Election Officer(s) will issue a call for nominations, publish the list of voters, and open the call for exceptions. One week before the election the call for nominations and exceptions will be closed. The election will be open for voting not less than two weeks and not more than four. The results of the election will be announced within one week of closing the election. New Steering Committee members will take office on December 1 of each year.

Election Officer(s)

Six weeks or more before the election, the Steering Committee will appoint between one and three Election Officer(s) to administer the election. Elections Officers will be Knative community members in good standing who are eligible to vote, are not running for Steering in that election, who are not currently part of the Steering Committee and can make a public promise of impartiality. They will be responsible for:

  • Making all announcements associated with the election
  • Preparing and distributing electronic ballots
  • Judging exception requests
  • Assisting candidates in preparing and sharing statements
  • Tallying voting results according to the rules in this charter

Eligibility to Vote

Anyone who has at least 50 contributions in the last 12 months is eligible to vote in the Steering election. Contributions are defined as opening PRs, reviewing and commenting on PRs, opening and commenting on issues, writing design docs, commenting on design docs, helping people on slack, participating in working groups, and other efforts that help advance Knative the project.

This dashboard shows only GitHub based contributions and does not capture all the contributions we value. We expect this metric not to capture everyone who should be eligible to vote. If a community member has had significant contributions over the past year but is not captured in the stats.knative.dev dashboard, they will be able to submit an exception form to the Elections Officer(s) who will then review and determine whether this member should be eligible to vote. All exceptions, and the reasons for them, will be recorded in a log that will be available to Steering and the TOC.

The electoral roll of all eligible voters will be captured at knative/community/steering-elections/$YEAR/voters.md and the voters’ guide will be captured at knative/community/steering-elections/$YEAR/README.md, similar to the kubernetes election process and identical to the TOC election process.

We are committed to an inclusive process and will adapt future eligibility requirements based on community feedback.

Candidate Eligibility

Community members must be eligible to vote in order to stand for election (this includes voters who qualify for an exception). Candidates may self-nominate or be nominated by another eligible member. There are no term limits for KSC members. Nothing prevents a qualified member from serving on both the TOC and SC simultaneously.

To run for a Contributing seat, a candidate must additionally be at least a project Member as defined in ROLES.

End-user seats are planned to enable employees of organizations which use but do not sell Knative-derived products. The mechanics of eligibility for end-user seats are still in progress; it is expected that end-user seats will add to the current Steering options to specific include end-user perspectives in the decision-making process.

Voting Procedure

Elections will be held using a time-limited Condorcet ranking on CIVS using the Schulze method. The top vote-getters will be elected to the open seats, with the exceptions for company representation discussed below. This is the same process used for TOC elections.

Limitations on Company Representation

No more than two seats may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). Additionally, each End-User seat (when available) must belong to an employee from a different organization. If the results of an election result in greater than two employees of the same organization, the lowest vote getters from any particular employer will be removed until representation on the committee is down to two.

If employers change because of job changes, acquisitions, or other events, in a way that would yield more than 2 seats being held by employees of the same organization, sufficient members of the committee must resign until only two employees of the same employer are left. If it is impossible to find sufficient members to resign, all employees of that organization will be removed and new special elections held. In the event of a question of company membership (for example evaluating independence of corporate subsidiaries) a majority of all non-involved Steering Committee members will decide.

Vacancies

In the event of a resignation or other loss of an elected SC member, the candidate with the next most votes from the previous election will be offered the seat, provided that person otherwise qualifies to join the SC. This process will continue until the seat is filled.

In case this fails to fill the seat, a special election for that position will be held as soon as possible, unless the regular SC election is less than 7 weeks away. Eligible voters from the most recent election will vote in the special election. Eligibility will not be redetermined at the time of the special election. Any replacement SC member will serve out the remainder of the term for the person they are replacing, regardless of the length of that remainder.

Transition

In order to transition from the original, organization-appointed Steering Committee structure (the “bootstrap” committee), elections will be phased in over 14 months.

In October 2020, two positions will be elected, including two Contributing seats and zero End-User seats (because end-user seat mechanics are still being worked out). One Google, one IBM/RedHat, and one VMware seat will be retained from the current Steering Committee.

In October or November 2021, the three remaining “bootstrap SC” seats will be replaced by elected seats (three Contributing and hopefully one End-User seat).

Changes to the charter

Changes to the KSC charter may be proposed via a PR on the charter itself. Amendments are accepted with majority consent of the committee as per the decision process outlined above.

Proposals and amendments to the charter are available for at least a period of one week for comments and questions before a vote will occur.

Authority, Facilitation, and Decision Making in Knative

Ideally most decisions will be made at the lowest possible level within the project: within individual working groups. When this is not possible for technical decisions, the TOC can help facilitate a conversation to work through the contended issue. When facilitation by the TOC does not resolve the contended issue, the Steering Committee can help facilitate. When facilitation by the SC does not resolve the contention, the SC may have to make a decision.

Note that if the SC is called to resolve contended decisions regularly, it is a symptom of a larger problem in the community that will need to be addressed.

Portions of this document are adapted from the Istio Steering Committee documentation, and other portions are copied from the Kubernetes Steering Committee, both of which are licensed under the Apache License 2.0.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License.