diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md index 63c450b1911..d974f9be982 100644 --- a/committee-steering/governance/wg-governance.md +++ b/committee-steering/governance/wg-governance.md @@ -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 @@ -25,6 +23,27 @@ over its formation and disbanding. - Documenting other governance bodies such as sub-projects or SIGs - Changing the status of existing Working Groups/SIGs/Sub-projects +## Working Group Relationship To SIGs +Assets owned by the Kubernetes project (e.g. code, docs, blogs, processes, etc) are owned and +managed by [SIGs](sig-governance.md). The exception to this is specific assets that may be owned +by Working Groups, as outlined below. + +Working Groups provide structure for governance and communication channels, and as such may +own the following types of assets: + +- Calendar Events +- Slack Channels +- Discussion Forum Groups + +Working Groups are distinct from SIGs in that they are intend to: + +- facilitate collaboration across SIGs +- facilitate an exploration of a problem / solution through a group with minimal governmental overhead + +Working Groups will typically have stake holders whose participation is in the +context of one or more SIGs. These SIGs should be documented as stake holders of the Working Group +(see Creation Process). + ## Is it a Working Group? Yes, if... - It does not own any code - It has a clear goal measured through a specific deliverable or deliverables @@ -62,8 +81,7 @@ requirements for that are: - chair information - meeting information - contact methods -- any sig stakeholders -- any subproject stakeholders +- any [sig](sig-governance.md) 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 +110,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 diff --git a/governance.md b/governance.md index 1c7d0807320..ca4a648182c 100644 --- a/governance.md +++ b/governance.md @@ -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. - -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. +forming a Working Group. -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