Address PR comments

Author: pwittrock

committee-steering/governance/working-group-formation-process.md renamed to committee-steering/governance/wg-governance.md

@@ -1,16 +1,17 @@
-# Kubernetes Working Group Formation Process - Proposal
+# Kubernetes Working Group Formation and Disbandment
 
 Draft 1.0 // Jaice Singer DuMars // June, 2018
 
 ## Process Overview and Motivations
-As opposed to “Birds of a Feather” or discussion groups, Working Groups provide a more formal avenue for disparate
-groups to intellectually collaborate around a common problem, craft a balanced position, and disband. Because they
-represent the interests of multiple special interest groups, they are a vehicle for consensus building, not
-construction. By design, the code under discussion resides in either multiple parts of the project, or is in the
-process of being extracted to an external repository.
+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
+building.  If code is developed as part of collaboration within the Working Group, that code will be housed in an
+appropriate repository as described in the [repositories document].  The merging of this code into the repository
+will be governed by the standard policies regarding submitting code to that repository (e.g. developed within one or
+more Subprojects owned by SIGs).
 
-Because a Working Group is an acknowledged part of the Kubernetes governance model, a process is necessary for
-formation and disbanding, as well as guidance on what authority is vested in the group by the steering committee.
+Because a working group is an official part of the Kubernetes project it is subject to steering committee oversight
+over its formation and disbanding.
 
 ## Goals of the process
 
@@ -28,12 +29,8 @@ formation and disbanding, as well as guidance on what authority is vested in the
 - It does not own any code
 - It has a clear goal measured through a specific deliverable or deliverables
 - It is temporary in nature and will be disbanded after reaching its stated goal(s)
-- It requires input from more than one SIG/sub-project to come up with an adequately-vetted deliverable with reasonable
-  stakeholder consensus
-- It is formulating vendor/implementation-agnostic deliverables
 
 ## Creation Process Description
-
 Working Group formation is less tightly-controlled than SIG formation since they:
 
 - Do not own code
@@ -65,16 +62,18 @@ requirements for that are:
 - chair information
 - meeting information
 - contact methods
+- any sig stakeholders
+- any subproject stakeholders
 
-The pull request should be labeled with the SIG stakeholders and committee/steering. And since GitHub notifications
+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,
 and the steering committee with a link to the PR. A member of the community admin team will place a /hold on it
 until it has an LGTM from at least one chair from each of the stakeholder SIGs, and a simple majority of the steering
 committee.
 
 Once merged, the Working Group is officially chartered until it either completes its stated goal, or disbands
-voluntarily due to new facts, member attrition, or other issues. Working groups should strive to make regular
-reports to stakeholder SIGs in order to ensure the mission is still aligned with the current state.
+voluntarily (e.g. due to new facts, member attrition, change in direction, etc). Working groups should strive to
+make regular reports to stakeholder SIGs in order to ensure the mission is still aligned with the current state.
 
 Deliverables (documents, diagrams) for the group should be stored in the directory created for the Working Group.
 If the deliverable is a KEP, it would be helpful to link it in the closed formation/charter PR for future reference.
@@ -85,3 +84,4 @@ References
 - [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ 
 
 
+[repository document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md

governance.md

@@ -116,6 +116,9 @@ 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.
 
+See [working group governance] for more details about forming and disbanding Working
+Groups.
+
 ## Committees
 
 Some topics, such as Security or Code of Conduct, require
@@ -171,5 +174,6 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md).
 [sig governance]: /sig-governance.md
 [owners]: community-membership.md#subproject-owner
 [short template]: committee-steering/governance/sig-charter-template.md
+[working group governance]: committee-steering/governance/wg-governance.md
 
 [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()