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

Follow on working group gov

This commit is contained in:
Phillip Wittrock 2018-10-16 14:31:31 -07:00
parent 699174c491
commit cbcd362eeb
2 changed files with 5 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
committee-steering/governance/wg-governance.md
View File

@ -1,7 +1,5 @@
# Kubernetes Working Group Formation and Disbandment
Draft 1.0 // Jaice Singer DuMars // June, 2018
## Process Overview and Motivations
Working Groups provide a formal avenue for disparate groups to collaborate around a common problem, craft a balanced
position, and disband. Because they represent the interests of multiple groups, they are a vehicle for consensus
@ -62,8 +60,7 @@ requirements for that are:
- chair information
- meeting information
- contact methods
- any sig stakeholders
- any subproject stakeholders
- any [sig or subproject](sig-governance.md#project-management) stakeholders
The pull request should be labeled with any SIG stakeholders and committee/steering. And since GitHub notifications
are not a reliable means to contact people, an email should be sent to the mailing lists for the stakeholder SIGs,
@ -92,7 +89,7 @@ Working Groups will be disbanded if either of the following is true:
- Zoom
The current Chair may step down at any time. When they do so, a new Chair may be selected through lazy consensus
within the Working Group.
within the Working Group, and [sigs.yaml](../../sigs.yaml) should be updated.
References

24
governance.md
View File

@ -103,35 +103,17 @@ Subprojects for each SIG are documented in [sigs.yaml](sigs.yaml).
We need community rallying points to facilitate discussions/work
regarding topics that are short-lived or that span multiple SIGs.
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.
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.
forming a Working Group.
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.
It's encouraged to keep a clear record of all accomplishments that's publicly
accessible. Like SIGs, working group communications and meetings should be
open and be recorded for later viewing.
See [working group governance] for more details about forming and disbanding
Working Groups.
Working groups are documented in [sigs.yaml](sigs.yaml).
See [working group governance] for more details about forming and disbanding Working
Groups.
## Committees