Skip to content

Commit

Permalink
Add more prominent details around SIGs/WG/Committees
Browse files Browse the repository at this point in the history
Signed-off-by: Joe Beda <[email protected]>
  • Loading branch information
jbeda committed Apr 1, 2018
1 parent 4cb27c0 commit 01a8a86
Show file tree
Hide file tree
Showing 2 changed files with 38 additions and 19 deletions.
28 changes: 21 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,16 +13,26 @@ issues, mailing lists, conferences, etc.

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.
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 are open in both proceedings and membership.
The purpose of a SIG is to own and develop a set of subprojects (defined below).
* **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,
described in a `README` or `CONTRIBUTING` file in the SIG
folder in this repo (e.g. [sig-cli/CONTRIBUTING](sig-cli/CONTRIBUTING.md)),
and its own mailing list, slack channel, etc.
See the [full governance doc](governance.md) for more details on these groups.

Kubernetes is a set of subprojects, each shepherded by a Special Interest Group (SIG).
Most decision making in Kubernetes happens through SIGs.

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](sig-cli/CONTRIBUTING.md)), 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),
please follow [these instructions](./generator) that detail how our docs are auto-generated.
Expand All @@ -34,6 +44,10 @@ lead to many relevant technical topics.

## Contribute

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 [find something to work on]
Expand Down
29 changes: 17 additions & 12 deletions governance.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,8 +55,8 @@ itself. Examples:
* Horizontal: Scalability, Architecture
* Project: Testing, Release, Docs, PM, Contributor Experience

SIGs must have at least one and ideally two SIG leads at any given
time. SIG leads are intended to be organizers and facilitators,
SIGs must have at least one and ideally two SIG chairs at any given
time. SIG chairs are intended to be organizers and facilitators,
responsible for the operation of the SIG and for communication and
coordination with the other SIGs, the Steering Committee, and the
broader community.
Expand All @@ -65,7 +65,8 @@ Each SIG must have a charter that specifies its scope (topics,
subsystems, code repos and directories), responsibilities, areas of
authority, how members and roles of authority/leadership 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
are being developed, but SIGs should be relatively free to customize
or change how they operate, within some broad guidelines and
Expand Down Expand Up @@ -109,6 +110,8 @@ This is the purpose of Working Groups (WG). The intent is to make
Working Groups relatively easy to create and to deprecate, once
inactive.

Working groups do not own any code or subprojects. Instead, they are a place for people to discuss topics that cross SIG boundaries.

## Committees

Some topics, such as Security or Code of Conduct, require
Expand All @@ -117,7 +120,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
committees as needed, for bounded or unbounded duration. Membership
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
charter.

Expand All @@ -144,17 +147,17 @@ to its charter, will own the decision. In the case of extended debate
or deadlock, decisions may be escalated to the Steering Committee,
which is expected to be uncommon.

The exact processes and guidelines for such cross-project
communication have yet to be formalized, but when in doubt, use
[email protected] and make an announcement at the
community meeting.
The [KEP process] is being developed as a way to facilitate definition, agreement and communication of efforts that cross SIG boundaries.
SIGs are encouraged to use this process for larger efforts.
This process is also available for smaller efforts within a SIG.

# Repository guidelines

All repositories under Kubernetes github orgs, such as kubernetes and kubernetes-incubator,
should follow the procedures outlined in the [incubator document](incubator.md). All code projects
use the [Apache Licence version 2.0](LICENSE). Documentation repositories should use the
[Creative Commons License version 4.0](https://git.k8s.io/website/LICENSE).
All new repositories under Kubernetes github orgs should follow the process outlined in the [kubernetes repository guidelines].

All code projects use the [Apache Licence version 2.0](LICENSE). Documentation repositories should use the [Creative Commons License version 4.0](https://git.k8s.io/website/LICENSE).

Note that "Kubernetes incubator" process has been documented in favor of the new guidelines.

# CLA

Expand All @@ -163,6 +166,8 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md).
[community membership]: /community-membership.md
[sig governance]: /sig-governance.md
[owners]: community-membership.md#subproject-owner
[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)]()

0 comments on commit 01a8a86

Please sign in to comment.