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.

Sign up for GitHub

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

Follow on working group gov #2814

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cbcd362
Follow on working group gov
pwittrock Oct 16, 2018
bdc2317
Address PR comments
pwittrock Nov 13, 2018
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
7 changes: 2 additions & 5 deletions committee-steering/governance/wg-governance.md
View file
Open in desktop
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 Down Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dare I ask why sig or subproject? asking from a perspective of wanting to update sigs.yaml to have working groups specify which entities they interface with

I had assumed it was just going to be a sigs: field, now I'm guessing it would look like sigs: and subprojects: fields and wondering why the additional complexity

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(ref #2176)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to this question

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PTAL. I removed the line about projects.


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 +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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

markdown nit: (/sigs.yaml)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done


References

Expand Down
24 changes: 3 additions & 21 deletions governance.md
View file
Open in desktop
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