From 699174c491d9c8ba57addf62db776ae950c72b91 Mon Sep 17 00:00:00 2001 From: Phillip Wittrock Date: Sun, 23 Sep 2018 22:32:54 -0700 Subject: [PATCH] Copy document authored by @jdumars into a PR. (Thanks Jaice) --- .../governance/wg-governance.md | 103 ++++++++++++++++++ governance.md | 4 + 2 files changed, 107 insertions(+) create mode 100644 committee-steering/governance/wg-governance.md diff --git a/committee-steering/governance/wg-governance.md b/committee-steering/governance/wg-governance.md new file mode 100644 index 00000000000..63c450b1911 --- /dev/null +++ b/committee-steering/governance/wg-governance.md @@ -0,0 +1,103 @@ +# 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 +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 official part of the Kubernetes project it is subject to steering committee oversight +over its formation and disbanding. + +## 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) + +## 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 +- any sig stakeholders +- any subproject 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, +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 (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. + +## Disbandment Process Description + +Working Groups will be disbanded if either of the following is true: + +- There is no long a Chair + - (with a 4 week grace period) +- None of the communication channels for the Working Group have been in use for the goals outlined at the founding of + the Working Group + - (with a 3 month grace period) + - Slack + - Email Discussion Forum + - 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. + +References + +- [1] https://github.com/kubernetes/community/pull/1994 +- [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 \ No newline at end of file diff --git a/governance.md b/governance.md index 7eff8e96816..1c7d0807320 100644 --- a/governance.md +++ b/governance.md @@ -130,6 +130,9 @@ open and be recorded for later viewing. Working groups are documented in [sigs.yaml](sigs.yaml). +See [working group governance] for more details about forming and disbanding Working +Groups. + ## Committees Some topics, such as Security or Code of Conduct, require @@ -185,5 +188,6 @@ All contributors must sign the CNCF CLA, as described [here](CLA.md). [sig charter process]: committee-steering/governance/README.md [short template]: committee-steering/governance/sig-governance-template-short.md [kubernetes repository guidelines]: kubernetes-repositories.md +[working group governance]: committee-steering/governance/wg-governance.md [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/governance.md?pixel)]()