Copy document authored by @jdumars into a PR. (Thanks Jaice)

Author: pwittrock

committee-steering/governance/working-group-formation-process.md

@@ -0,0 +1,87 @@
+# Kubernetes Working Group Formation Process - Proposal
+
+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.
+
+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.
+
+## Goals of the process
+
+- An easy-to-navigate process for those wishing to establish and eventually disband a new Working Group
+- Simple guidance and differentiation on where a Working Group makes sense, and does not
+- Clear understanding that no authority is vested in a Working Group
+- Ensure all future Working Groups conform with this process
+
+## Non-goals of the process
+
+- Documenting other governance bodies such as sub-projects or SIGs
+- Changing the status of existing Working Groups/SIGs/Sub-projects
+
+## 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
+- 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
+- Have a clear entry and exit criteria
+- Do not have any organizational authority, only influence
+
+Therefore, Working Group formation begins with the organizers asking themselves some important questions that
+should eventually be reflected in a pull request on sigs.yaml:
+
+1. What is the exact problem this group is trying to solve?
+1. What is the artifact that this group will deliver, and to whom?
+1. How does the group know when the problem solving process is completed, and it is time for the Working Group to
+   dissolve?
+1. Who are all of the stakeholders involved in this problem this group is trying to solve (SIGs, steering committee,
+   other Working Groups)?
+1. What are the meeting mechanics (frequency, duration, roles)?
+1. Does the goal of the Working Group represent the needs of the project as a whole, or is it focused on the interests
+   of a narrow set of contributors or companies?
+1. Who will chair the group, and ensure it continues to meet these requirements?
+1. Is diversity well-represented in the Working Group?
+
+Once the above questions have been answered, the pull request against sigs.yaml can be created. Once the generator
+is run, this will in turn create the OWNERS_ALIASES file, readme files, and the main SIGs list.  The minimum
+requirements for that are:
+
+- name
+- directory
+- mission statement
+- chair information
+- meeting information
+- contact methods
+
+The pull request should be labeled with the 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.
+
+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.
+
+References
+
+- [1] https://github.com/kubernetes/community/pull/1994
+- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ 
+
+