Skip to content

Follow on working group gov #2814

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 19, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 23 additions & 5 deletions committee-steering/governance/wg-governance.md
Original file line number Diff line number Diff line change
@@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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,
Expand Down Expand Up @@ -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

Expand Down
24 changes: 3 additions & 21 deletions governance.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 [email protected] 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

Expand Down