-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add more prominent details around SIGs/WG/Committees
Signed-off-by: Joe Beda <[email protected]>
- Loading branch information
Showing
2 changed files
with
38 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
|
@@ -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 | ||
|
@@ -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 | ||
|
@@ -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. | ||
|
||
|
@@ -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 | ||
|
||
|
@@ -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)]() |