Follow on working group gov

2 files changed, 5 insertions, 26 deletions

diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md
index 63c450b1..3c478b3d 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
@@ -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
 
diff --git a/governance.md b/governance.md
index 1c7d0807..ca4a6481 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