From 90895ac55e0719f6efa5f4549f99d397255124a8 Mon Sep 17 00:00:00 2001 From: Paul Schweigert Date: Tue, 22 Oct 2024 12:17:59 -0400 Subject: [PATCH] replacing TOC references with KSC ones (#1623) Signed-off-by: Paul S. Schweigert --- .github/ISSUE_TEMPLATE/new-repo.md | 8 +- .github/ISSUE_TEMPLATE/question.md | 2 +- CONSENSUS.md | 4 +- REPOSITORY-GUIDELINES.md | 14 +-- ROLES.md | 6 +- SLACK-GUIDELINES.md | 6 +- elections/README.md | 21 +---- groups/committee-oversight/OWNERS | 6 -- groups/committee-oversight/groups.yaml | 17 ---- groups/committee-steering/groups.yaml | 7 ++ groups/restrictions.yaml | 3 - mechanics/CREATING-AN-EXTENSIONS-REPO.md | 10 +-- mechanics/GDRIVE.md | 4 +- mechanics/GOLANG-POLICY.md | 2 +- mechanics/MATURITY-LEVELS.md | 6 +- mechanics/ROADMAPS.md | 10 +-- mechanics/TOC.md | 108 ----------------------- mechanics/WORKING-GROUP-PROCESSES.md | 8 +- working-groups/WORKING-GROUPS.md | 3 +- working-groups/security/responding.md | 4 +- 20 files changed, 53 insertions(+), 196 deletions(-) delete mode 100644 groups/committee-oversight/OWNERS delete mode 100644 groups/committee-oversight/groups.yaml delete mode 100644 mechanics/TOC.md diff --git a/.github/ISSUE_TEMPLATE/new-repo.md b/.github/ISSUE_TEMPLATE/new-repo.md index ed8d1551..3f41bb68 100644 --- a/.github/ISSUE_TEMPLATE/new-repo.md +++ b/.github/ISSUE_TEMPLATE/new-repo.md @@ -25,9 +25,9 @@ Sponsoring WG: This area is used to track the [repo creation process](https://github.com/knative/community/blob/main/mechanics/CREATING-AN-EXTENSIONS-REPO.md). The _requestor_ and _sponsoring WG lead_ should perform the steps listed below and cross out the checkmarks when done. -The TOC is involved only in the **TOC Gate** steps. +The Steering Committee is involved only in the **KSC Gate** steps. -- [ ] Add this issue to the [TOC project board](https://github.com/orgs/knative/projects/43) for review. You are responsible for moving your entry on the board to "Needs Discussion" or "In Progress" as you move forward in this checklist. +- [ ] Add this issue to the [Steering Committee project board](https://github.com/orgs/knative/projects/52) for review. You are responsible for moving your entry on the board to "Needs Discussion" or "In Progress" as you move forward in this checklist. _You may not be able to use the Projects quick menu on this page. In that case, go to the project board and use the **Add cards** interface._ @@ -36,11 +36,11 @@ _You may not be able to use the Projects quick menu on this page. In that case, - [ ] Grant `Knative Admin` the `admin` privilege. - [ ] Grant the sponsoring WG the `write` privilege. -**TOC Gate**: _Once the TOC has approved the above, it will merge and Peribolos will create an empty repository._ +**KSC Gate**: _Once the KSC has approved the above, it will merge and Peribolos will create an empty repository._ - [ ] (golang) Send a PR to add aliases for `knative.dev/$REPONAME` import paths ([sample](https://github.com/knative/docs/pull/4160)). -- [ ] Have a lead from the sponsoring WG bootstrap the Git repository by using an +- [ ] Have a lead from the sponsoring WG bootstrap the Git repository by using an appropriate "template" repository ([basic](https://github.com/knative-extensions/wg-repository), [sample-controller](https://github.com/knative-extensions/sample-controller), [sample-source](https://github.com/knative-extensions/sample-source)). diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md index a9dcfb57..c1ae4d66 100644 --- a/.github/ISSUE_TEMPLATE/question.md +++ b/.github/ISSUE_TEMPLATE/question.md @@ -1,5 +1,5 @@ --- name: Question -about: Question for TOC or Steering Committee +about: Question for Steering Committee title: "" --- diff --git a/CONSENSUS.md b/CONSENSUS.md index 97079954..7f0cab2c 100644 --- a/CONSENSUS.md +++ b/CONSENSUS.md @@ -28,8 +28,8 @@ When lazy consensus is used, you should: * Allow time for your colleagues to read and think about the message * Please allow an appropriate amount of time, at least 3 business days * Give healthy consideration to reasonable objections - * If consensus cannot be achieved within the discussion, you should attempt to resolve it within the appropriate working group, then engage the TOC or Steering as appropriate if that fails -* Record the decision in writing + * If consensus cannot be achieved within the discussion, you should attempt to resolve it within the appropriate working group, then engage Steering as appropriate if that fails +* Record the decision in writing * In increasing order of durability: decision announced in meeting minutes, send a mail to the mailing list, approval in Google Doc by WG lead, GitHub PR (possibly in “docs” directory or the like) --- diff --git a/REPOSITORY-GUIDELINES.md b/REPOSITORY-GUIDELINES.md index c274b93f..b388b303 100644 --- a/REPOSITORY-GUIDELINES.md +++ b/REPOSITORY-GUIDELINES.md @@ -75,9 +75,9 @@ steps: - A proposal to remove the repository is brought to the attention of the Technical Oversight Committee through a GitHub issue posted in the [community](https://github.com/knative/community) repo. - - Feedback is encouraged during a Technical Oversight Committee meeting before + - Feedback is encouraged during a Steering Committee meeting before any action is taken. -- Once the TOC has approved of the removal, if the repo is not moving to another +- Once the Steering Committee has approved of the removal, if the repo is not moving to another actively maintained project: - The repo description is edited to start with the phrase "[EOL]" - All open issues and PRs are closed @@ -120,7 +120,7 @@ Note: prior art here from the [Kubernetes community](https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md). Working groups are allowed to request repositories that meet the following -requirements. The Steering Committee and TOC will maintain the process and +requirements. The Steering Committee will maintain the process and perform the repository creation steps to ensure that the following requirements have been met: @@ -153,7 +153,7 @@ have been met: - Clearly document the stability and API guarantees (both in the top-level `README.md` and by using appropriate API versioning for Kubernetes apigroups). - - The TOC will maintain a template which will be used during the creation of + - The Steering Committee will maintain a template which will be used during the creation of new repositories. Existing repositiories are encouraged to update their `README`s from time to time as the format changes. @@ -163,7 +163,7 @@ have been met: - APIs under `knative.dev` should: 1. Be under a subdomain managed by the owning Working Group (e.g. - `sources.knative.dev`, not `knative.dev`). The TOC is considered the + `sources.knative.dev`, not `knative.dev`). The Steering Committee is considered the authority for assigning subdomains to working groups. 1. Coordinate with the Working Group in API naming to avoid collisions or @@ -181,8 +181,8 @@ of pluggability. The following are not required to create a working-group-owned repository: - Steering approval (see ["the fine print"](#the-fine-print)) -- TOC approval - - TOC may request certain naming patterns (e.g. `kn-plugin` for client WG) +- Steering Committee approval + - Steering Committee may request certain naming patterns (e.g. `kn-plugin` for client WG) - Solving an unique problem (exploring different approaches to problems outside the core is actively encouraged!) diff --git a/ROLES.md b/ROLES.md index 90af466b..126ad203 100644 --- a/ROLES.md +++ b/ROLES.md @@ -235,7 +235,7 @@ The following apply to the area / component for which one would be a lead. - Roadmap. Establish and maintain a roadmap for the working group outlining the areas of focus for the working group over the next 6 months. - - Report. Report current status to the TOC meeting every 6 weeks. + - Report. Report current status to the Steering Committee meeting every 6 weeks. - Expected to work to holistically maintain the health of the project through: @@ -316,12 +316,12 @@ Approver. not fulfilling their documented responsibilities for more than 1 month. - This MAY be done through a super-majority vote of managers, or if there are not enough active managers to get a super-majority of votes cast, then - removal MAY occur through exception process to the TOC. The PR removing the + removal MAY occur through exception process to the Steering Committee. The PR removing the manager should be open for at least 72 hours. - Prior to voting to remove a manager, leads SHOULD reach out to the affected manager and see if they need to take a leave. - Membership disagreements MAY be escalated to the WG leads. WG lead membership - disagreements MAY be escalated to the TOC. + disagreements MAY be escalated to the Steering Committee. - Managers MAY decide to step down at anytime and nominate a replacement who will be approved through the regular process for that role. diff --git a/SLACK-GUIDELINES.md b/SLACK-GUIDELINES.md index 10cfcc8e..c1499897 100644 --- a/SLACK-GUIDELINES.md +++ b/SLACK-GUIDELINES.md @@ -44,7 +44,6 @@ project, and includes all communication mediums. ## Admins Members of the -[Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and [Knative Steering Committee (KSC)](STEERING-COMMITTEE.md) are also the administrators for the Knative Slack instance. @@ -52,8 +51,7 @@ Slack admins should make sure to mention this in the “What I do” section of their Slack profile, as well as for which time zone. To connect: please reach out in the #slack-admins channel or DM (Direct Message) -a member of the [KSC](STEERING-COMMITTEE.md) or -[TOC](TECH-OVERSIGHT-COMMITTEE.md). +a member of the [KSC](STEERING-COMMITTEE.md). ### Admin expectations and guidelines @@ -144,7 +142,7 @@ in the purpose or pinned docs of that channel. ## Threaded Conversations -Slack threads in public channels are extremely useful for quickly and openly collaborating with your fellow contributors. +Slack threads in public channels are extremely useful for quickly and openly collaborating with your fellow contributors. Unfortunately, while Slack threads are good for quick discussion, they serve as a poor record of decisions. Discoverability and searchability of threads isn't nearly as good as alternatives (see below), particularly for contributors arriving weeks or months later. For this reason it's important that Slack discussions make their way to less ephemeral and more comprehensive artifacts for sharing ideas and proposals with the wider community. diff --git a/elections/README.md b/elections/README.md index 309f490a..39df448e 100644 --- a/elections/README.md +++ b/elections/README.md @@ -7,7 +7,7 @@ type: "docs" # Knative Elections -This document outlines how to conduct Knative elections. See [TOC election process](../mechanics/TOC.md) and [Steering Committee election process](../mechanics/SC.md) for more information of how the committee decides when to have elections, eligibility for voting, eligibility for candidacy, maximal representation, etc. +This document outlines how to conduct Knative elections. See [Steering Committee election process](../mechanics/SC.md) for more information of how the committee decides when to have elections, eligibility for voting, eligibility for candidacy, maximal representation, etc. ## Process @@ -15,7 +15,7 @@ This document outlines how to conduct Knative elections. See [TOC election proce 2. Prepare the election repository - * Make knative/community/elections/$YEAR-TOC or knative/community/elections/$YEAR-SC + * Make knative/community/elections/$YEAR-SC * Create an OWNERS file in the above directory with the election officers as approvers / reviewers. * Create the README.md in the above directory, this is the voter's guide * Copy over the voter's guide from the previous year. The voter's guide is the single source of truth for the election that year! All annoucements and notices should link to this document. @@ -36,7 +36,7 @@ This document outlines how to conduct Knative elections. See [TOC election proce 4. Executing the Election in Elekto * Elections will be held using [Elekto](https://elekto.dev/), an online voting tool created - by CNCF intern Manish Sahani and administered by Josh Berkus. + by CNCF intern Manish Sahani and administered by Josh Berkus. * It relies on GitHub Oauth for access to ballots * More details can be found in the [Elekto documentation](https://elekto.dev/docs/) * Remember to send periodic reminders about key deadlines and to encourage people to vote. @@ -57,18 +57,6 @@ This document outlines how to conduct Knative elections. See [TOC election proce ## Roles and Responsibilities: -### Technical Oversight Committee - -- [Recuses themselves from public election activities][election-recusal] -- May vote -- May answer questions about general election specifics, ie: - - Where do I find the schedule? - - How do I vote? -- Will not answer questions about specific candidates, or anything that could be construed as endorsing, ie: - - How is $candidate doing so far? (PS - we don't know anyway) - - Who are your favorite candidates? - - ### Steering Committee - Oversees the election, including appointing election officers, approving dates, and monitoring the process @@ -92,7 +80,7 @@ This document outlines how to conduct Knative elections. See [TOC election proce - Who are your favorite candidates? - Manage the voting process within Elekto - Generate the voter guide and list of voters according to the criteria for that year's election -- Manage the exception process - Review applicants and add approved ones to the voter's list +- Manage the exception process - Review applicants and add approved ones to the voter's list - Track candidates - Monitor groups for nominations - Update the community regularly @@ -103,4 +91,3 @@ This document outlines how to conduct Knative elections. See [TOC election proce Diary for 2023 Knative TOC election can be found in this [Gist](https://gist.github.com/aliok/136be152fef14912b9a73eb753b3267b) for reference. [election-recusal]: https://github.com/kubernetes/steering/blob/main/elections.md#steering-committee-and-election-officer-recusal - diff --git a/groups/committee-oversight/OWNERS b/groups/committee-oversight/OWNERS deleted file mode 100644 index ef4b7c6c..00000000 --- a/groups/committee-oversight/OWNERS +++ /dev/null @@ -1,6 +0,0 @@ -# The OWNERS file is used by prow to automatically merge approved PRs. - -approvers: -- technical-oversight-committee -reviewers: -- technical-oversight-committee diff --git a/groups/committee-oversight/groups.yaml b/groups/committee-oversight/groups.yaml deleted file mode 100644 index 2c33e03e..00000000 --- a/groups/committee-oversight/groups.yaml +++ /dev/null @@ -1,17 +0,0 @@ -# Technical Oversight Committee -groups: - - email-id: toc@knative.team - name: toc - description: |- - Technical Oversight Committee Email - settings: - AllowExternalMembers: "false" - WhoCanPostMessage: "ANYONE_CAN_POST" - ReconcileMembers: "true" - owners: - - david.hadas@gmail.com - - dprotaso@gmail.com - - dsimansk@redhat.com - - d.simansky@gmail.com - - paul@paulschweigert.com - - paulschw@us.ibm.com diff --git a/groups/committee-steering/groups.yaml b/groups/committee-steering/groups.yaml index a9a8a12b..b8649a61 100644 --- a/groups/committee-steering/groups.yaml +++ b/groups/committee-steering/groups.yaml @@ -12,6 +12,13 @@ groups: - evan.k.anderson@gmail.com - naina.sng@gmail.com - salaboy@gmail.com + - david.hadas@gmail.com + - dprotaso@gmail.com + - dsimansk@redhat.com + - d.simansky@gmail.com + - paul@paulschweigert.com + - paulschw@us.ibm.com + - email-id: elections@knative.team name: elections diff --git a/groups/restrictions.yaml b/groups/restrictions.yaml index 96ad0d4c..ccc0f952 100644 --- a/groups/restrictions.yaml +++ b/groups/restrictions.yaml @@ -2,9 +2,6 @@ restrictions: - path: "committee-code-of-conduct/groups.yaml" allowedGroups: - "^code-of-conduct@knative.team$" - - path: "committee-oversight/groups.yaml" - allowedGroups: - - "^toc@knative.team$" - path: "committee-steering/groups.yaml" allowedGroups: - "^steering@knative.team$" diff --git a/mechanics/CREATING-AN-EXTENSIONS-REPO.md b/mechanics/CREATING-AN-EXTENSIONS-REPO.md index fa464b3c..e37dc4a9 100644 --- a/mechanics/CREATING-AN-EXTENSIONS-REPO.md +++ b/mechanics/CREATING-AN-EXTENSIONS-REPO.md @@ -23,13 +23,13 @@ A Working Group Lead (either [execution](../ROLES.md#working-group-execution-lead)) may request a new repo in `knative-extensions` by filing an issue in the [knative/community](https://github.com/knative/community/issues/new?template=new-repo.md) -repo. Once filed, the TOC should handle these promptly, though it should also be +repo. Once filed, the Steering Committee should handle these promptly, though it should also be considered fine to ping members or the group on Slack if it hasn't been acted on -in a few days. Generally, the request will be granted, though the TOC may have +in a few days. Generally, the request will be granted, though the Steering Committee may have additional questions or suggest an alternate mechanism in some cases. Some of the following steps may require permissions that are only available to -the TOC or Steering Committee, though others are largely self-service or require +the Steering Committee, though others are largely self-service or require other WGs to review and approve impacting changes. ### Technical requirements @@ -46,7 +46,7 @@ other WGs to review and approve impacting changes. `knative-extensions`, but the Google CLA bot and OWNERS files/tide merge should be enforced. -## Process (to be executed by TOC or Steering member) +## Process (to be executed by Steering member) 1. (Requires Org owner) Create the new repo in https://github.com/knative-extensions using the "New" button. Set the repo to @@ -54,7 +54,7 @@ other WGs to review and approve impacting changes. 1. (Requires repo write/org owner) Create: - - `OWNERS` file listing TOC and WG members as approvers, and WG members as + - `OWNERS` file listing Steering Committee and WG members as approvers, and WG members as reviewers - `CODE-OF-CONDUCT.md` (that links to diff --git a/mechanics/GDRIVE.md b/mechanics/GDRIVE.md index 0fca56cf..92e83ba0 100644 --- a/mechanics/GDRIVE.md +++ b/mechanics/GDRIVE.md @@ -33,7 +33,7 @@ All steering committee members have “Super Admin” [privileges](https://suppo #### Technical Oversight Committee -The technical oversight committee members each have a knative.team GSuite account. This is to allow TOC members to assist with some of the GSuite automation and GDrive migration. In addition to this, TOC members will need a knative.team account to allow people without a knative.team account into public meetings hosted on Google Hangouts. +The technical oversight committee members each have a knative.team GSuite account. This is to allow Steering Committee members to assist with some of the GSuite automation and GDrive migration. In addition to this, Steering Committee members will need a knative.team account to allow people without a knative.team account into public meetings hosted on Google Hangouts. #### Working Group Leads @@ -58,4 +58,4 @@ There are several mailing lists set up to manage permission groups (some could a The Knative.team GSuite is a [Business Standard](https://workspace.google.com/intl/en/pricing.html) GSuite Plan. This is required so that WG meetings have the ability to record meetings. If we need changes made to the GSuite package-type on this account, [April Nassi](mailto:anassi@google.com) can help with this. -The GSuite org is currently paid by Google. [Mary Radomile](mailto:maryr@google.com) is the point of contact if we need help re: billing. +The GSuite org is currently paid by Google. [Mary Radomile](mailto:maryr@google.com) is the point of contact if we need help re: billing. diff --git a/mechanics/GOLANG-POLICY.md b/mechanics/GOLANG-POLICY.md index 7214a47f..65686473 100644 --- a/mechanics/GOLANG-POLICY.md +++ b/mechanics/GOLANG-POLICY.md @@ -24,7 +24,7 @@ Major Golang version bumps (i.e. 1.14 to 1.15) should be made deliberately and s be taken too lightly. Such a change should not happen too closely to a release of Knative. If the bump would be within two weeks of the Knative release cycle, it should be postponed until the next release to allow for thorough testing and hardening. Exceptions -to this should be discussed and agreed upon through the TOC. +to this should be discussed and agreed upon through the Steering Committee. Since such a version bump can potentially be breaking to some repositories, the change should be announced and discussed and agreed upon between the impacted working groups. diff --git a/mechanics/MATURITY-LEVELS.md b/mechanics/MATURITY-LEVELS.md index 92a12e16..b8ef67c2 100644 --- a/mechanics/MATURITY-LEVELS.md +++ b/mechanics/MATURITY-LEVELS.md @@ -90,14 +90,14 @@ Additional requirements beyond "initiating": - Unit test automation meeting the Knative standards with respect to coverage and flakiness / test failures. - Provide at least monthly progress reports at the appropriate WG(s). WGs should - roll these reports up into their TOC reports. + roll these reports up into their SC reports. - User-facing documentation for the following areas: install, usage - Contributor facing documentation for: development setup - Ongoing contributions from multiple contributors and management of user issues, etc. Usable projects which meet the criteria for core (i.e. developer-facing -abstractions with wide utility, beta+ APIs) may apply to the TOC and SC for +abstractions with wide utility, beta+ APIs) may apply to the SC for [migration to core](#migration-to-core), but approval is more likely for projects in the "Stable" category. @@ -148,7 +148,7 @@ support the project with bug and security fixes as applicable ## Migration to Core -A stable project may apply to the SC and TOC to be admitted to the Knative core. +A stable project may apply to the SC to be admitted to the Knative core. Not all stable projects are suitable for "core"; this is a judgement as to the degree to which the project should be considered a part of a "expected developer experience" across Knative installations. Projects may be graded on the diff --git a/mechanics/ROADMAPS.md b/mechanics/ROADMAPS.md index a7c1c2c0..b94794c6 100644 --- a/mechanics/ROADMAPS.md +++ b/mechanics/ROADMAPS.md @@ -11,11 +11,11 @@ The are multiple benefits of this process: * Working Groups should already be using GitHub issues to track their upcoming work; adding project boards minimizes the amount of additional bookkeeping needed to produce a roadmap. * Having a single process for all Working Groups makes it easier for new contributors to approach a WG and contribute. * Org-level projects are editable via the web GUI for all org members, making the additional permissions required simple and light-weight. -* Having roadmaps which track which items are at which stage of implementation is helpful in [managing the flow of work](https://en.wikipedia.org/wiki/Kanban) for contributors, WG leads, and the [TOC](../TECHNICAL-OVERSIGHT-COMMITTE.md). +* Having roadmaps which track which items are at which stage of implementation is helpful in [managing the flow of work](https://en.wikipedia.org/wiki/Kanban) for contributors, WG leads, and the [Steering Committee](../STEERING-COMMITTE.md). ## Roadmap Columns and Guidance -Roadmaps should have the following columns. Additional columns can be added temporarily, but it should be possible to map them to these groupings during a TOC review: +Roadmaps should have the following columns. Additional columns can be added temporarily, but it should be possible to map them to these groupings during a Steering Committee review: ### `In Progress` Column These are issues / feature requests which are currently being implemented (code written) by contributors. The goal should be that contributors should be able to focus their efforts on _one_ of these issues at a time, and complete the issue efficiently without a lot of context switching. @@ -58,8 +58,8 @@ This is the intake column for new issues and feature requests which haven't been See https://github.com/knative/community/issues/746 for the original discussion / impetus of this process. -* These guidelines may be subject to refinement and change in the future. The [TOC](../TECH-OVERSIGHT-COMMITTEE.md) will be responsible for updates and communication of process changes. Working Group leads _are_ encouraged to experiment with the process within the general guidelines laid out above. +* These guidelines may be subject to refinement and change in the future. The [Steering Committee](../STEERING-COMMITTEE.md) will be responsible for updates and communication of process changes. Working Group leads _are_ encouraged to experiment with the process within the general guidelines laid out above. -* The TOC does not yet have a recommended process for handling issues which have reached "In Progress" but have some type of time-based delay (e.g. feature is released in "alpha", needs to be progressed to "beta" after one release). One option is to create a new "Ready To Work" issue like `Post-1.3: promote $FEATURE to Beta` and close the original issue, but this is up to Working Group leads to manage. +* The Steering Committee does not yet have a recommended process for handling issues which have reached "In Progress" but have some type of time-based delay (e.g. feature is released in "alpha", needs to be progressed to "beta" after one release). One option is to create a new "Ready To Work" issue like `Post-1.3: promote $FEATURE to Beta` and close the original issue, but this is up to Working Group leads to manage. -* TOC reviews will generally focus on management and possibly coordination implications of work items, and will generally rely on the judgement of the working group in terms of which items to complete first. +* Steering Committee reviews will generally focus on management and possibly coordination implications of work items, and will generally rely on the judgement of the working group in terms of which items to complete first. diff --git a/mechanics/TOC.md b/mechanics/TOC.md deleted file mode 100644 index e4f85bd9..00000000 --- a/mechanics/TOC.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: "Knative TOC election process" -linkTitle: "TOC election process" -weight: 30 -type: "docs" -aliases: - - /contributing/mechanics/toc/ ---- - -# Guiding Principles - -- The TOC seat should be earned by individuals and not company participation -- Members of the TOC should be exemplary members of the community who have - demonstrated our community values -- The TOC should be made up of individuals from different working groups and - vendors so that we have a diverse group of thought and input - -# Composition - -The TOC will have five seats with a 2 year term. - -There will be an annual election to determine the composition of the TOC for the -following year. Ideally, three seats will be up for election in one year and two will be -up for election the following year. If more than 3 seats are up for re-election, then the -term for 1 or more seats will be 1 year as needed to maintain a balance of having either -2 or 3 seats up for election each year. The 2 year seats will be given to the most -preferred candidates in the election. - -# Candidate Eligibility - -Current TOC members and -[Approvers](https://github.com/knative/community/blob/main/ROLES.md#approver) -with at least 3 months tenure are eligible to stand for election. The approver -role may be held within either -[Knative](https://github.com/knative/community/blob/main/peribolos/knative.yaml) or -[Knative Extensions](https://github.com/knative/community/blob/main/peribolos/knative-extensions.yaml). -Candidates may self-nominate or be nominated by another eligible member. The -approximate time commitment of a TOC member is around 8 hours per week. - -# Voter Eligibility - -Anyone who has at least 50 contributions in the last 12 months is eligible to -vote in the TOC 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 etc. - -[This dashboard](https://knative.devstats.cncf.io/d/9/developer-activity-counts-by-repository-group-table?orgId=1&var-period_name=Last%20year) -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 steering committee who will then review and -determine whether this member should be marked as an exception. - -Additionally, anyone serving on the SC or TOC will -automatically be eligible to vote regardless of their number of contributions. - -All eligible voters will be captured at -`knative/community/elections/$YEAR-TOC/voters.yaml` and the voters’ guide -will be captured at `knative/community/elections/$YEAR-TOC/README.md` -similar to the kubernetes election process. - -We are committed to an inclusive process and will adapt future eligibility -requirements based on community feedback. - -# Election Process - -Elections will be held using a time-limited -[Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) ranking on -[Elekto](https://elekto.io/). The top vote-getters will be elected to -the open seats. - -## Election Officers - -The steering committee will be the election officers for the technical oversight -committee elections, or they may delegate this responsibility and appoint -election officers. - -## Vacancies - -In the event of a resignation or other loss of an elected TOC member with less -than three months left until the next regular annual election, the Steering -Committee shall appoint a qualified contributor to fill that TOC seat until -that election. - -Otherwise the next most preferred candidate from the previous annual -election will be offered the seat. If the seat cannot be filled from the -previous annual election, the next most preferred candidate from the most -recent special election will be offered the seat. 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. Eligible voters from the most recent election will -vote in the special election (ie: eligibility will not be redetermined at the -time of the special election). - -Any replacement TOC member who was appointed more than three months -before the next TOC election will serve out the remainder of the term for -the person they are replacing, regardless of the length of that -remainder. - ---- - -Except as otherwise noted, the content of this page is licensed under the -[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), -and code samples are licensed under the -[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/mechanics/WORKING-GROUP-PROCESSES.md b/mechanics/WORKING-GROUP-PROCESSES.md index 4c2cf639..22882cec 100644 --- a/mechanics/WORKING-GROUP-PROCESSES.md +++ b/mechanics/WORKING-GROUP-PROCESSES.md @@ -56,7 +56,7 @@ meet the bar for a new WG, it's likely that other participants in the community have ideas and opinions, and up-front conversations can help to focus the shape and scope of the solution space. -The TOC and existing WGs should enable these conversations (e.g. setting up +The Steering Committee and existing WGs should enable these conversations (e.g. setting up one-off meetings, creating slack channels, etc). Once the community has identified a substantial architectural area which would benefit from long-lived, concerted and focused design, then you should consider creating a new working @@ -69,12 +69,12 @@ group. To do so, you need to: - The goals of the working group (problems being solved) - The scope of the working group (topics, subsystems, code repos, areas of - responsibility). Also include items which are out of scope. The TOC will be + responsibility). Also include items which are out of scope. The Steering Committee will be looking at this to make sure that there are appropriate touch-points and contracts between WGs when considering larger problems. Here are some example charters to help indicate the expected size of the - document. The main things that the TOC will be looking for are: + document. The main things that the Steering Committee will be looking for are: - [Event Delivery WG](https://docs.google.com/document/d/11SPnDRIJ6CGo5ElPGMWc25tX2iQfJfaiZwzBhruUZQw/edit) - [Eventing Sources WG](https://docs.google.com/document/d/1XQo9DUbNdOIxf37eKSG1ULEyxydcG0YGeO13wBjQpEE/edit) @@ -224,7 +224,7 @@ the situation. To trigger an escalation, create an issue in the project's repo and assign it to the **@knative/tech-oversight-committee** team. The Steering Committee, as a last resort, provides the final escalation path for -any repository or working group issue that cannot be resolved by the TOC. +any repository or working group issue that cannot be resolved by the Steering Committee. --- diff --git a/working-groups/WORKING-GROUPS.md b/working-groups/WORKING-GROUPS.md index b020e9c8..e859aad5 100644 --- a/working-groups/WORKING-GROUPS.md +++ b/working-groups/WORKING-GROUPS.md @@ -30,7 +30,7 @@ Some working groups (mostly those with a plug-in or extension model) end up responsible for a set of GitHub repos, one for each extension. This allows for easier dependency management; in these cases, one or more repo prefix names will be recorded as canonical "extension names" to allow WGs to be responsible for -their own namespace without needing to get TOC approval for each repo name. +their own namespace without needing to get Steering Committee approval for each repo name. Additionally, all working groups should hold regular meetings, which should be added to the @@ -389,4 +389,3 @@ Except as otherwise noted, the content of this page is licensed under the [Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/), and code samples are licensed under the [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0). - diff --git a/working-groups/security/responding.md b/working-groups/security/responding.md index 09c89c9e..29bc1376 100644 --- a/working-groups/security/responding.md +++ b/working-groups/security/responding.md @@ -17,10 +17,10 @@ disclosures of vulnerabilities (while being large enough to spread the work of responding to vulnerabilities) and should be composed of those who will actively work on the fix and disclosure process. -Anyone who is an Approver, Lead or TOC Member in a Knative Project, or who is +Anyone who is an Approver, Lead or Steering Committee Member in a Knative Project, or who is an employee of a member of the Embargo list working in a security-focused or knative-focused role may apply to be a member of this group. -The application is approved or rejected by the TOC. +The application is approved or rejected by the Steering Committee. ## Identifying a Fix Lead