Proposal: Update for Knative Governance [WIP] (#1017)

* Update for governance proposal

* Add credit to Kubernetes source doc

* Adding the TBD seats with my proposed allocations.

* Clean up formatting

* Clarify meeting frequency

* Clarify voting requirements

* Update w/ feedback

* Clarify who to contact

* Updates from feedback

* Add committee term duration

* Define procedure for changing charter

* Rebase on master

* Fix location of repo guidelines

* Fix page index

* Remove extranous sample files
This commit is contained in:
Ryan Gregg 2019-04-03 13:32:37 -07:00 committed by Mark Chmarny
parent b9c4445c15
commit 13da240891
5 changed files with 213 additions and 50 deletions

View File

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

View File

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

View File

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

View File

@ -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
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.
- Define policy for the creation and administration of community groups,
including [Working Groups](./WORKING-GROUPS.md) and Committees.
## Delegated authority
- Define and evolve project governance structures and policies, including
project role assignment and contributor promotion.
KSC may choose to delegate its authority to other committees as-needed. The
committee currently recognizes this delegated authority for:
- Approve members of the Tech Oversight Committee.
- Technical guidance is delegated to the [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md).
- Management of project assets
## Committee Meetings
- Control access to, establish processes regarding, and provide a final
escalation path for any Knative repository.
KSC meets every two weeks, or as-needed. Meetings are held online.
- Guided by the TOC for normal business.
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.
- 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.
Meeting notes are available to members of the knative-dev mailing list
(link to be added).
- 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.
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 Mechanics
## Committee members
The committee's operation and charter may be changed by unanimous consent of
committee members.
Seats on the Steering Committee are held by an organization, not by the
individual.
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.
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.
<!-- TODO ## Committee Meeting -->
The current membership of the committee is currently (listed alphabetically by name):
## Committee Members
| &nbsp; | 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 | |
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.
There are currently four unfilled seats, as indicated by TBD.
| &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) |
### 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.
In case of extended absence, the organization of the absent member may appoint
a single delegate from the same company during the absence.
## Changes to the charter
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.
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.
## Getting in touch
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

View File

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