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