Proposal: Update for Knative Governance [WIP]

contributing/README.md

@@ -22,19 +22,21 @@ Other Documents
 
 - [Code of Conduct](./CODE-OF-CONDUCT.md) - all contributors must abide by the
   code of conduct
-- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on
-  becoming a contributor
+- [Values](./VALUES.md) - shared goals and values for the community
+- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on becoming
+  a contributor
 - [Working Groups](./WORKING-GROUPS.md) - describes our various working groups
-- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how
-  working groups operate
+- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how working
+  groups operate
+- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering committee
 - [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md) - describes our
   technical oversight committee
-- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering
-  committee
 - [Community Roles](./ROLES.md) - describes the roles individuals can assume
   within the Knative community
 - [Reviewing and Merging Pull Requests](./REVIEWING.md) - how we manage pull
   requests
+- [Repository Guidelines](./REPOSITORY-GUIDELINES.md) - how we create and remove
+  core repositories
 
 ## Introduction
 

contributing/REPOSITORY-GUIDELINES.md

@@ -0,0 +1,69 @@
+# Knative Repository Guidelines
+
+This document outlines a structure for creating and associating code repositories
+with the Knative project. It also describes how and when repositories are removed.
+
+## Core Repositories
+
+Core repositories are considered core components of Knative. They are utilities, tools,
+applications, or libraries that form or support the foundation of the project.
+
+Core repositories are all those located under the
+[github.com/knative organization](https://github.com/knative).
+
+### Core Repository Requirements
+
+* Repository must live under github.com/knative/project-name
+* Must adopt the Knative Code of Conduct
+* All code projects must use the Apache License version 2.0.
+* Documentation repositories must use Creative Commons License version 4.0.
+* All OWNERS must be members of the Knative community.
+* Repository creation must be approved by the Technical Oversight Committee.
+
+## Removing Repositories
+
+As important as it is to add new repositories, it is equally important to prune
+repositories when necessary. See [Grounds for removal](#grounds-for-removal).
+
+It is important to the success of Knative that all Knative repositories stay
+active, healthy, and aligned with the scope and mission of project.
+
+### Grounds for removal
+
+Core repositories may be removed from the project if they are deemed _inactive_.
+Inactive repositories are those that meet any of the following criteria:
+
+* There are no longer any active maintainers for the project, and no replacements can be found.
+* All PRs and issues have gone un-addressed for longer than six months.
+* There have been no new commits or other changes in more than a year.
+* The contents have been folded into another actively maintained project.
+
+### Procedure for removal
+
+When a repository has been deemed eligible for removal, we take the following steps:
+
+* A proposal to remove the repository is brought to the attention of the Technical Oversight Committee
+  through a GitHub issue posted in the [docs](https://github.com/knative/docs) repo.
+  * Feedback is encouraged during a Technical Oversight Committee meeting before any action is taken.
+* Once the TOC 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
+  * All external collaborates are removed
+  * All webhooks, apps, integrations, or services are removed
+  * GitHub pages are disabled
+  * The repo is marked as archived using GitHub's archive feature
+  * The removal is announced on the knative-dev mailing list
+
+This procedure maintains the complete record of issues, PRs, and other contributions. It leaves
+the repository read-only and makes it clear that the repository is retired and no longer maintained.
+
+---
+
+Contents of this page are adopted from the
+[Kubernetes repository guidelines](https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md),
+which is licensed under Apache License 2.0.
+
+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).

contributing/SLACK-GUIDELINES.md

@@ -27,16 +27,15 @@ project, and includes all communication mediums.
 
 ## Admins
 
-- @mchmarny
-- @isdal
-- @dewitt
+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, mention one of us in
-the specific channel where you have a question, or DM (Direct Message) one of us
-privately.
+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).
 
 ### Admin Expectations and Guidelines
 

contributing/STEERING-COMMITTEE.md

@@ -5,65 +5,156 @@ weight: 40
 type: "docs"
 ---
 
-The Knative Steering Committee (SC) defines, evolves, and defends the vision,
-values, mission, and scope of the project. _The Steering Committee is a
-work-in-progress._
+The Knative Steering Committee (KSC) is the ultimate authority for the Knative
+project, and governs all aspects of the project.
+
+The governance of Knative is an open, living document, and will continue to
+evolve as the community and project change. We expect over time we will adapt
+the way we run this committee, based on feedback from the community.
 
 - [Charter](#charter)
+- [Delegated authority](#delegated-authority)
+- [Committee Meetings](#committee-meetings)
 - [Committee Mechanics](#committee-mechanics)
 - [Committee Members](#committee-members)
+  - [Allocation of seats](#allocation-of-seats)
+- [Decision process](#decision-process)
+- [Changes to the charter](#changes-to-the-charter)
+- [Getting in touch](#getting-in-touch)
 
 ## Charter
 
-- Non-technical project oversight
-
-  - Define policy for the creation and administration of community groups,
-    including [Working Groups](./WORKING-GROUPS.md) and Committees.
-
-  - Define and evolve project governance structures and policies, including
-    project role assignment and contributor promotion.
-
-  - Approve members of the Tech Oversight Committee.
-
-- Management of project assets
-
-  - Control access to, establish processes regarding, and provide a final
-    escalation path for any Knative repository.
+1. Define, evolve, and promote the vision, values, mission, and scope of the project.
+1. 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](./WORKING-GROUPS.md) and committees.
+1. Steward, control access, delegate access, and establishes processes regarding,
+   all Knative project resources and has the final say in the disposition of
+   those resources.
+1. Manage the Knative brand and decide which things can be called "Knative" and
+   how that mark can be used in relation to other efforts or vendors.
+1. Confirm/reject nominations to the KSC from organizations who are allocated seats.
+1. Confirm/reject nominations to the Technical Oversight Committee.
+1. Receive and handle reports about [code of conduct](./CODE-OF-CONDUCT.md)
+   violations and maintain confidentiality.
+1. 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.
+1. 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:
+
+- Technical guidance is delegated to the [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md).
+
+## Committee Meetings
+
+KSC meets every two weeks, or as-needed. Meetings are held online.
+
+Given the private nature of many of these discussions (e.g. privacy, private
+emails to the committee, code of conduct violations, escalations, disputes
+between members, security reports, etc.) meetings are held in private.
+
+Meeting notes are available to members of the knative-dev mailing list
+(link to be added).
+
+Questions and proposals for changes to governance are posted as issues in the
+[docs repo](https://github.com/knative/docs), and the KSC invites your feedback
+there. See [Getting in touch](#getting-in-touch) for other options.
+
+## Committee members
+
+Seats on the Steering Committee are held by an organization, not by the
+individual.
+
+The committee was created as the project was in its infancy, in order to
+tackle governance and overall project strategy. Because of the nature of the
+project and funding required, it was decided that strong corporate leadership
+was necessary for the project to ensure velocity. As the project grows and
+matures the KSC will, from time to time, consider if this policy should be
+changed.
+
+The current membership of the committee is currently (listed alphabetically by name):
+
+|                                                     | Member         | Organization | Profile                                  |
+| -------------------------------------------------------- | -------------- | ------------ | ---------------------------------------- |
+| <img width="30px" src="https://github.com/dewitt.png">   | DeWitt Clinton | Google       | [@dewitt](https://github.com/dewitt)     |
+| <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny   | Google       | [@mchmarny](https://github.com/mchmarny) |
+| <img width="30px" src="https://github.com/isdal.png">    | Tomas Isdal    | Google       | [@isdal](https://github.com/isdal)       |
+|   | TBD | Google   |        |
+|   | TBD | IBM      |        |
+|   | TBD | Pivotal  |        |
+|   | TBD | Red Hat  |        |
+
+There are currently four unfilled seats, as indicated by TBD.
+
+### Allocation of seats
+
+Seats on the steering committee are allocated based upon contribution
+to the project by an organization. No final decision has been made on the exact
+formula.
+
+As the project continues to grow, we expect to add additional seats to the
+committee, ensuring that those contributing to the project are properly
+represented.
+
+- After a seat is allocated to an organization, the organization shall nominate
+  a candidate to be confirmed by KSC. The committee reserves the right to not
+  confirm a candidate, in which the organization would need to nominate a new
+  candidate
+- Members of the committee may step down at any time. When a member steps down,
+  their organization shall nominate a new candidate.
+- If a member leaves their organization, the organization must nominate a new
+  committee member to replace them following the nomination and confirmation
+  process.
+- If an organization is unable to seat a candidate, the KSC reserves the right
+  to reallocate the seat to another organization.
+- Changes to the number of seats, which company seats are allocated to, and
+  nominations to the committee are confirmed by majority vote of the committee
+  members.
+- In situations where the organization which holds a seat is no longer a viable
+  entity (e.g. merger, dissolution, bankruptcy) the KSC will make a decision on
+  how to reallocate that seat. Seats do not automatically transfer to any
+  organization.
+- Members on the committee have a 1 year term from their confirmation, and may
+  be reconfirmed to the committee at the end of their term.
+
+## Decision process
+
+The steering committee desires to always reach consensus.
+
+Decisions are made in meetings when a quorum of the members are present and may
+pass with majority of the committee supporting it.
+
+Quorum is considered reached when at least half of the members are present.
 
-  - Guided by the TOC for normal business.
+In case of extended absence, the organization of the absent member may appoint
+a single delegate from the same company during the absence.
 
-  - Control and delegate access to and establish processes regarding other
-    project resources/assets not covered by the above, including web sites and
-    their domains, blogs, social-media accounts, etc.
+## Changes to the charter
 
-  - Manage the Knative brand to decide which things can be called “Knative” and
-    how that mark can be used in relation to other efforts or vendors.
+Changes to the KSC charter may be proposed via a Pull Request on the charter
+itself. Amendments are accepted with majority consent of the committee.
 
-## Committee Mechanics
+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.
 
-The committee's operation and charter may be changed by unanimous consent of
-committee members.
+## Getting in touch
 
-In case of extended absence, an absent member will be considered to be in
-agreement after 8 days have passed since a proposal was accepted by all present
-members. An absent member may appoint a single delegate during absences.
-
-<!-- TODO ## Committee Meeting -->
-
-## Committee Members
-
-The members of the Steering Committee are shown below. Membership in the SC is
-determined by current level of contribution to the project. Contribution is
-periodically reviewed to ensure proper recognition.
-
-| &nbsp;                                                   | Member         | Company | Profile                                  |
-| -------------------------------------------------------- | -------------- | ------- | ---------------------------------------- |
-| <img width="30px" src="https://github.com/dewitt.png">   | DeWitt Clinton | Google  | [@dewitt](https://github.com/dewitt)     |
-| <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny   | Google  | [@mchmarny](https://github.com/mchmarny) |
-| <img width="30px" src="https://github.com/isdal.png">    | Tomas Isdal    | Google  | [@isdal](https://github.com/isdal)       |
+If you'd like to reach out to the committee, please drop a note
+to [knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com).
+This is a private discussion list to which all members of the committee have access.
 
 ---
 
+Portions of this document are adapted from the
+[Istio Steering Committee](https://github.com/istio/community/blob/master/STEERING-COMMITTEE.md)
+documentation, which is 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](https://creativecommons.org/licenses/by/4.0/),
 and code samples are licensed under the

contributing/WORKING-GROUP-PROCESSES.md

@@ -188,10 +188,12 @@ Leads from all affected working groups generally work together and come to an
 agreeable conclusion.
 
 In all cases, remaining blocking issues can be raised to the
-[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve
-the situation. To trigger an escalation, create an issue in the
-`knative/serving` repo and assign it to the
-**@knative/tech-oversight-committee** team.
+[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve 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.
 
 ---