kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add more prominent details around SIGs/WG/Committees 

Signed-off-by: Joe Beda <joe.github@bedafamily.com>
This commit is contained in:
Joe Beda 2018-03-31 21:04:18 -07:00
parent 1cb83ad3be
commit 2a04222581
No known key found for this signature in database
GPG Key ID: 4296898C63A3591D
2 changed files with 61 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
README.md
View File

@ -13,16 +13,27 @@ issues, mailing lists, conferences, etc.
For more specific topics, try a SIG. For more specific topics, try a SIG.
## SIGs ## Governance
Kubernetes is a set of subprojects, each shepherded by a Special Interest Group (SIG). Kubernetes has three types of groups that are officially supported:
A first step to contributing is to pick from the [list of kubernetes SIGs](sig-list.md). * **Committees** are named sets of people that are chartered to take on sensitive topics.
This group is encouraged to be as open as possible while achieving its mission but, because of the nature of the topics discussed, private communications are allowed.
Examples of committees include the steering committee and things like security or code of conduct.
* **Special Interest Groups (SIGs)** are persistent open groups that focus on a part of the project.
SIGs must have open and transparent proceedings.
Anyone is welcome to participate and contribute provided they follow the Kubernetes Code of Conduct.
The purpose of a SIG is to own and develop a set of **subprojects**.
* **Subprojects** Each SIG can have a set of subprojects.
These are smaller groups that can work independently.
Some subprojects will be part of the main Kubernetes deliverables while others will be more speculative and live in the `kubernetes-sigs` github org.
* **Working Groups** are temporary groups that are formed to address issues that cross SIG boundaries.
Working groups do not own any code or other long term artifacts.
Working groups can report back and act through involved SIGs.
A SIG can have its own policy for contribution, See the [full governance doc](governance.md) for more details on these groups.
described in a `README` or `CONTRIBUTING` file in the SIG
folder in this repo (e.g. [sig-cli/CONTRIBUTING](sig-cli/CONTRIBUTING.md)), A SIG can have its own policy for contribution, described in a `README` or `CONTRIBUTING` file in the SIG folder in this repo (e.g. [sig-cli/CONTRIBUTING.md](sig-cli/CONTRIBUTING.md)), and its own mailing list, slack channel, etc.
and its own mailing list, slack channel, etc.
If you want to edit details about a SIG (e.g. its weekly meeting time or its leads), If you want to edit details about a SIG (e.g. its weekly meeting time or its leads),
please follow [these instructions](./generator) that detail how our docs are auto-generated. please follow [these instructions](./generator) that detail how our docs are auto-generated.
@ -34,7 +45,11 @@ lead to many relevant technical topics.
## Contribute ## Contribute
The [Contributor Guide](contributors/guide/README.md) provides detailed instructions on how to get your ideas and bug fixes seen and accepted, including: A first step to contributing is to pick from the [list of kubernetes SIGs](sig-list.md).
Start attending SIG meetings, join the slack channel and subscribe to the mailing list.
SIGs will often have a set of "help wanted" issues that can help new contributors get involved.
The [Contributor Guide](contributors/guide/README.md) provides detailed instruction on how to get your ideas and bug fixes seen and accepted, including:
1. How to [file an issue] 1. How to [file an issue]
1. How to [find something to work on] 1. How to [find something to work on]
1. How to [open a pull request] 1. How to [open a pull request]

62
governance.md
View File

@ -26,10 +26,10 @@ See [community membership]
# Community groups # Community groups
The project has 4 main types of groups: The project has 4 main types of groups:
1. Special Interest Groups, SIGs * Special Interest Groups, SIGs
2. Subprojects * Subprojects
3. Working Groups, WGs * Working Groups, WGs
4. Committees * Committees
## SIGs ## SIGs
@ -52,8 +52,8 @@ itself. Examples:
* Horizontal: Scalability, Architecture * Horizontal: Scalability, Architecture
* Project: Testing, Release, Docs, PM, Contributor Experience * Project: Testing, Release, Docs, PM, Contributor Experience
SIGs must have at least one and ideally two SIG leads at any given SIGs must have at least one and ideally two SIG chairs at any given
time. SIG leads are intended to be organizers and facilitators, time. SIG chairs are intended to be organizers and facilitators,
responsible for the operation of the SIG and for communication and responsible for the operation of the SIG and for communication and
coordination with the other SIGs, the Steering Committee, and the coordination with the other SIGs, the Steering Committee, and the
broader community. broader community.
@ -62,7 +62,8 @@ Each SIG must have a charter that specifies its scope (topics,
subsystems, code repos and directories), responsibilities, areas of subsystems, code repos and directories), responsibilities, areas of
authority, how members and roles of authority/leadership are authority, how members and roles of authority/leadership are
selected/granted, how decisions are made, and how conflicts are selected/granted, how decisions are made, and how conflicts are
resolved. A [short template] for intra-SIG governance has been resolved. See the [SIG charter process] for details on how charters are managed.
A [short template] for intra-SIG governance has been
developed in order to simplify SIG creation, and additional templates developed in order to simplify SIG creation, and additional templates
are being developed, but SIGs should be relatively free to customize are being developed, but SIGs should be relatively free to customize
or change how they operate, within some broad guidelines and or change how they operate, within some broad guidelines and
@ -79,7 +80,7 @@ community.
See [sig governance] for more details about current SIG operating See [sig governance] for more details about current SIG operating
mechanics, such as mailing lists, meeting times, etc. mechanics, such as mailing lists, meeting times, etc.
## Subprojects ### Subprojects
Specific work efforts within SIGs are divided into **subprojects**. Specific work efforts within SIGs are divided into **subprojects**.
Every part of the Kubernetes code and documentation must be owned by Every part of the Kubernetes code and documentation must be owned by
@ -106,15 +107,28 @@ This is the purpose of Working Groups (WG). The intent is to make
Working Groups relatively easy to create and to deprecate, once Working Groups relatively easy to create and to deprecate, once
inactive. inactive.
To propose a new working group, first find a SIG to sponsor the group. Working groups do not own any code or subprojects. Instead, they are a place for
Next, send a proposal to kubernetes-dev@googlegroups.com and also include people to discuss topics that cross SIG boundaries.
any potentially interested SIGs. Wait for public comment. If there's
enough interest, a new Working Group should be formed.
Create a new mailing list in the from of kubernetes-wg-group-name. Working Working groups are primarily used to facilitate topics of discussion that are in
scope for Kubernetes but that cross SIG lines. If a set of folks in the
community want to get together and discuss a topic, they can do so without
forming a Working Group. As a community we will be looking for other ways to
highlight and encourage a larger ecosystem (with things like slack channels)
without offering any official endorsement.
To propose a new working group, first find a SIG to sponsor the group.
Next, send a proposal to kubernetes-dev@googlegroups.com and also include
any potentially interested SIGs. Wait for public comment. If there's
enough interest, a new Working Group should be formed.
Create a new mailing list in the from of kubernetes-wg-group-name. Working
groups typically have a Slack channel as well as regular meetings on zoom. groups typically have a Slack channel as well as regular meetings on zoom.
It's encouraged to keep a clear record of all accomplishments that's publicly It's encouraged to keep a clear record of all accomplishments that's publicly
accessible. accessible. Like SIGs, working group communications and meetings should be
open and be recorded for later viewing.
Working groups are documented in [sigs.yaml](sigs.yaml).
## Committees ## Committees
@ -124,7 +138,7 @@ open and anyone can join, Committees do not have open membership and do
not always operate in the open. The steering committee can form not always operate in the open. The steering committee can form
committees as needed, for bounded or unbounded duration. Membership committees as needed, for bounded or unbounded duration. Membership
of a committee is decided by the steering committee. Like a SIG, a of a committee is decided by the steering committee. Like a SIG, a
committee has a charter and a lead, and will report to the steering committee has a charter and a chair, and will report to the steering
committee periodically, and to the community as makes sense, given the committee periodically, and to the community as makes sense, given the
charter. charter.
@ -151,17 +165,15 @@ to its charter, will own the decision. In the case of extended debate
or deadlock, decisions may be escalated to the Steering Committee, or deadlock, decisions may be escalated to the Steering Committee,
which is expected to be uncommon. which is expected to be uncommon.
The exact processes and guidelines for such cross-project The [KEP process] is being developed as a way to facilitate definition, agreement and communication of efforts that cross SIG boundaries.
communication have yet to be formalized, but when in doubt, use SIGs are encouraged to use this process for larger efforts.
kubernetes-dev@googlegroups.com and make an announcement at the This process is also available for smaller efforts within a SIG.
community meeting.
# Repository guidelines # Repository guidelines
All repositories under Kubernetes github orgs, such as kubernetes and kubernetes-incubator, All new repositories under Kubernetes github orgs should follow the process outlined in the [kubernetes repository guidelines].
should follow the procedures outlined in the [incubator document](incubator.md). All code projects
use the [Apache License version 2.0](LICENSE). Documentation repositories should use the Note that "Kubernetes incubator" process has been deprecated in favor of the new guidelines.
[Creative Commons License version 4.0](https://git.k8s.io/website/LICENSE).
# CLA # CLA
@ -170,6 +182,8 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md).
[community membership]: /community-membership.md [community membership]: /community-membership.md
[sig governance]: /sig-governance.md [sig governance]: /sig-governance.md
[owners]: community-membership.md#subproject-owner [owners]: community-membership.md#subproject-owner
[short template]: committee-steering/governance/sig-charter-template.md [sig charter process]: committee-steering/governance/README.md
[short template]: committee-steering/governance/sig-governance-template-short.md
[kubernetes repository guidelines]: kubernetes-repositories.md
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]() [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()