mirror of https://github.com/knative/docs.git
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:
parent
b9c4445c15
commit
13da240891
|
@ -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
|
||||
|
||||
|
|
|
@ -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).
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
- Guided by the TOC for normal business.
|
||||
|
||||
- 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.
|
||||
|
||||
- Manage the Knative brand to decide which things can be called “Knative” and
|
||||
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.
|
||||
|
||||
## Committee Mechanics
|
||||
## Delegated authority
|
||||
|
||||
The committee's operation and charter may be changed by unanimous consent of
|
||||
committee members.
|
||||
KSC may choose to delegate its authority to other committees as-needed. The
|
||||
committee currently recognizes this delegated authority for:
|
||||
|
||||
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.
|
||||
- Technical guidance is delegated to the [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md).
|
||||
|
||||
<!-- TODO ## Committee Meeting -->
|
||||
## Committee Meetings
|
||||
|
||||
## Committee Members
|
||||
KSC meets every two weeks, or as-needed. Meetings are held online.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
| | Member | Company | Profile |
|
||||
| -------------------------------------------------------- | -------------- | ------- | ---------------------------------------- |
|
||||
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.
|
||||
|
||||
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
|
||||
|
|
|
@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
|
Loading…
Reference in New Issue