replacing TOC references with KSC ones

Signed-off-by: Paul S. Schweigert <[email protected]>

.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)).

.github/ISSUE_TEMPLATE/question.md

@@ -1,5 +1,5 @@
 ---
 name: Question
-about: Question for TOC or Steering Committee
+about: Question for Steering Committee
 title: ""
 ---

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)
 
 ---

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!)
 

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.
 

SLACK-GUIDELINES.md

@@ -44,16 +44,14 @@ 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.
 
 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.
 

elections/README.md

@@ -7,15 +7,15 @@ 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
 
 1. Steering committee selects election officers.
 
 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
-

groups/committee-steering/groups.yaml

@@ -12,6 +12,13 @@ groups:
       - [email protected]
       - [email protected]
       - [email protected]
+      - [email protected]
+      - [email protected]
+      - [email protected]
+      - [email protected]
+      - [email protected]
+      - [email protected]
+
 
   - email-id: [email protected]
     name: elections

groups/restrictions.yaml

@@ -2,9 +2,6 @@ restrictions:
   - path: "committee-code-of-conduct/groups.yaml"
     allowedGroups:
       - "^[email protected]$"
-  - path: "committee-oversight/groups.yaml"
-    allowedGroups:
-      - "^[email protected]$"
   - path: "committee-steering/groups.yaml"
     allowedGroups:
       - "^[email protected]$"

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,15 +46,15 @@ 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
    public and include an "Apache License 2.0" but no `.gitignore` or `README`.
 
 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

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:[email protected]) can help with this.
 
-The GSuite org is currently paid by Google. [Mary Radomile](mailto:[email protected]) is the point of contact if we need help re: billing. 
+The GSuite org is currently paid by Google. [Mary Radomile](mailto:[email protected]) is the point of contact if we need help re: billing.

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.

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