|
| 1 | +# Kubernetes Working Group Formation and Disbandment |
| 2 | + |
| 3 | +Draft 1.0 // Jaice Singer DuMars // June, 2018 |
| 4 | + |
| 5 | +## Process Overview and Motivations |
| 6 | +Working Groups provide a formal avenue for disparate groups to collaborate around a common problem, craft a balanced |
| 7 | +position, and disband. Because they represent the interests of multiple groups, they are a vehicle for consensus |
| 8 | +building. If code is developed as part of collaboration within the Working Group, that code will be housed in an |
| 9 | +appropriate repository as described in the [repositories document]. The merging of this code into the repository |
| 10 | +will be governed by the standard policies regarding submitting code to that repository (e.g. developed within one or |
| 11 | +more Subprojects owned by SIGs). |
| 12 | + |
| 13 | +Because a working group is an official part of the Kubernetes project it is subject to steering committee oversight |
| 14 | +over its formation and disbanding. |
| 15 | + |
| 16 | +## Goals of the process |
| 17 | + |
| 18 | +- An easy-to-navigate process for those wishing to establish and eventually disband a new Working Group |
| 19 | +- Simple guidance and differentiation on where a Working Group makes sense, and does not |
| 20 | +- Clear understanding that no authority is vested in a Working Group |
| 21 | +- Ensure all future Working Groups conform with this process |
| 22 | + |
| 23 | +## Non-goals of the process |
| 24 | + |
| 25 | +- Documenting other governance bodies such as sub-projects or SIGs |
| 26 | +- Changing the status of existing Working Groups/SIGs/Sub-projects |
| 27 | + |
| 28 | +## Is it a Working Group? Yes, if... |
| 29 | +- It does not own any code |
| 30 | +- It has a clear goal measured through a specific deliverable or deliverables |
| 31 | +- It is temporary in nature and will be disbanded after reaching its stated goal(s) |
| 32 | + |
| 33 | +## Creation Process Description |
| 34 | +Working Group formation is less tightly-controlled than SIG formation since they: |
| 35 | + |
| 36 | +- Do not own code |
| 37 | +- Have a clear entry and exit criteria |
| 38 | +- Do not have any organizational authority, only influence |
| 39 | + |
| 40 | +Therefore, Working Group formation begins with the organizers asking themselves some important questions that |
| 41 | +should eventually be reflected in a pull request on sigs.yaml: |
| 42 | + |
| 43 | +1. What is the exact problem this group is trying to solve? |
| 44 | +1. What is the artifact that this group will deliver, and to whom? |
| 45 | +1. How does the group know when the problem solving process is completed, and it is time for the Working Group to |
| 46 | + dissolve? |
| 47 | +1. Who are all of the stakeholders involved in this problem this group is trying to solve (SIGs, steering committee, |
| 48 | + other Working Groups)? |
| 49 | +1. What are the meeting mechanics (frequency, duration, roles)? |
| 50 | +1. Does the goal of the Working Group represent the needs of the project as a whole, or is it focused on the interests |
| 51 | + of a narrow set of contributors or companies? |
| 52 | +1. Who will chair the group, and ensure it continues to meet these requirements? |
| 53 | +1. Is diversity well-represented in the Working Group? |
| 54 | + |
| 55 | +Once the above questions have been answered, the pull request against sigs.yaml can be created. Once the generator |
| 56 | +is run, this will in turn create the OWNERS_ALIASES file, readme files, and the main SIGs list. The minimum |
| 57 | +requirements for that are: |
| 58 | + |
| 59 | +- name |
| 60 | +- directory |
| 61 | +- mission statement |
| 62 | +- chair information |
| 63 | +- meeting information |
| 64 | +- contact methods |
| 65 | +- any sig stakeholders |
| 66 | +- any subproject stakeholders |
| 67 | + |
| 68 | +The pull request should be labeled with any SIG stakeholders and committee/steering. And since GitHub notifications |
| 69 | +are not a reliable means to contact people, an email should be sent to the mailing lists for the stakeholder SIGs, |
| 70 | +and the steering committee with a link to the PR. A member of the community admin team will place a /hold on it |
| 71 | +until it has an LGTM from at least one chair from each of the stakeholder SIGs, and a simple majority of the steering |
| 72 | +committee. |
| 73 | + |
| 74 | +Once merged, the Working Group is officially chartered until it either completes its stated goal, or disbands |
| 75 | +voluntarily (e.g. due to new facts, member attrition, change in direction, etc). Working groups should strive to |
| 76 | +make regular reports to stakeholder SIGs in order to ensure the mission is still aligned with the current state. |
| 77 | + |
| 78 | +Deliverables (documents, diagrams) for the group should be stored in the directory created for the Working Group. |
| 79 | +If the deliverable is a KEP, it would be helpful to link it in the closed formation/charter PR for future reference. |
| 80 | + |
| 81 | +## Disbandment Process Description |
| 82 | + |
| 83 | +Working Groups will be disbanded if either of the following is true: |
| 84 | + |
| 85 | +- There is no long a Chair |
| 86 | + - (with a 4 week grace period) |
| 87 | +- None of the communication channels for the Working Group have been in use for the goals outlined at the founding of |
| 88 | + the Working Group |
| 89 | + - (with a 3 month grace period) |
| 90 | + - Slack |
| 91 | + - Email Discussion Forum |
| 92 | + - Zoom |
| 93 | + |
| 94 | +The current Chair may step down at any time. When they do so, a new Chair may be selected through lazy consensus |
| 95 | +within the Working Group. |
| 96 | + |
| 97 | +References |
| 98 | + |
| 99 | +- [1] https://github.com/kubernetes/community/pull/1994 |
| 100 | +- [2] https://groups.google.com/a/kubernetes.io/d/msg/steering/zEY93Swa_Ss/C0ziwjkGCQAJ |
| 101 | + |
| 102 | + |
| 103 | +[repository document]: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md |
0 commit comments