Clarify process for Working Group formation #2702
Conversation
k8s-ci-robot
added
size/M
k8s-ci-robot
added
the
committee/steering
pwittrock
force-pushed
the
wg-formation
branch
from
cfc1bf8
to
4b682b6
Compare
|
/lgtm |
k8s-ci-robot
added
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
approved
|
|
||
| - name | ||
| - directory | ||
| - mission statement |
There was a problem hiding this comment.
Do we want to consider adding mentions of SIG stakeholders here? ref: #2176
| - 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 |
There was a problem hiding this comment.
Why is this item here? This seems unnecessarily limiting on the community. If a group of people in the Kubernetes community want to form a working group, why do they need the blessing of a SIG? This seems to vest SIGs with powers that they were never intended to have.
Taken to the extreme, this gives the SIGs collectively the power to limit the development of new ideas, even if the community wants to work on those ideas.
It doesn't seem to me that there is anything gained by blocking on SIG approval. And "adequately-vetted" feels like somehow working groups need to petition the powers that be for approval. I don't think that is in the spirit of a working group.
| 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 |
There was a problem hiding this comment.
I have no idea what "not construction" means. Does that mean that working groups don't write code? That doesn't seem correct... The following sentence clarifies this somewhat, I think what you really mean is that the code that a working group may write will land in a variety of SIGs and not in a specific repo owned by the working group.
| - 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 |
There was a problem hiding this comment.
I'm worried that this is overly broad and can be used to selectively block things.
As some concrete examples, what if we are working on ARM processor support. That isn't vendor agnostic, and yet it's probably useful and important. Same thing with something like Mellanox high-performance network interconnects, or even NVidia-specific GPU work.
I think we should rephrase this in terms of the behaviors we're hoping to prevent.
| - 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: |
There was a problem hiding this comment.
Do we really want WGs in sigs.yaml? (and if so, linkify for easy discovery)
| 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 |
There was a problem hiding this comment.
What is the purpose of this question? I think there are lots of working groups (e.g. multi-tenancy, machine learning, etc) that are interesting and important topics, but do not represent the needs of the project as a whole. (most people don't need multi-tenancy, only large scale kubernetes operators, most people don't run machine learning workloads)
I think this question as formed will limit innovation because new ideas are inherently only interesting to a narrow group of people, and only become generally needed by all once they are proven out. If we prevent working groups from forming for the purpose of innovation we're going to severely limit the ways in which Kubernetes can grow.
|
/hold I would like to see more opportunities for new ideas and outside innovation in this document. As it is currently written it seems aimed at making cross-SIG decisions, not at incubating new ideas for Kubernetes. Concretely, I don't think that something like ThirdPartyResources/CustomResourceDefinitions could have been a working group under these definitions, and yet it has turned out to be a critical part of the Kubernetes ecosystem. Having lived through it, I know that there is no way that SIG-Architecture or SIG-API Machinery (the relevant SIGs) would have approved a third-party resources working group, and thus the effort would have died. I think rather than focusing on SIGs and SIG approval, working groups should have some min-bar for community participation (e.g. 10 people from 5 companies affirming the value of the working group, [those numbers are 100% made up, but you get the idea) That will provide a valuable avenue for innovation independent of the SIGs while still ensuring that there is broad interest and cross-company value for Kubernetes. |
|
I think this is something the steering committee should hash out, and not necessarily this doc PR. I definitely understand @brendandburns comments and concerns, and don't want to see any project innovations stifled by restrictive covenants. On the other hand, if working groups are vested with some implicit power, as it appears Brendan is inferring, then that should be called out. There is absolutely nothing standing in the way of "Birds of a Feather" or like informal gatherings. I would venture to say that such groups would be given equal audience in SIG and community meetings. SIGs are not the gatekeepers of what code gets merged, it's ultimately individuals in the OWNERS file. To be clear, kubernetes/community#2702 specifically calls out that working groups are NOT vested with any binding decision-making authority. Their reason for being is to provide project resources (inclusion in sigs.yaml, a Zoom account, mailing list) to facilitate the reconciliation of some problem that requires consensus of more than one governing (SIG) body. If the working group asserts that whatever they are solving has some official approval that's not consistent with the stated governance model, unless of course the parties involved also have sub-project (OWNERS) authority. Working groups have the power of influence, demonstration, and consensus-building. I'm not sure how being explicit about this limits anyone's ability to contribute through normal project channels. My recommendation is that we better define what groups (BoF, or the like) are intended to exist outside of SIGs and promote innovation even if vendor-specific. I agree that infusion of new ideas is key to a vibrant project ecosystem. I am just not convinced that working groups are that vehicle. |
There was a problem hiding this comment.
We need to include a link to the definition of a working group at the top of this document. The only definition I know of lives here and it is insufficient. Is there another document that describes what a working group is more clearly?
I'd suggest we move what is and is not a working group into a document that describes what a working group is and be separated from the process of creating and disbanding working group.
|
|
||
| Draft 1.0 // Jaice Singer DuMars // June, 2018 | ||
|
|
||
| ## Process Overview and Motivations |
There was a problem hiding this comment.
The Process Overview and Motivations is worded in a way that would be confusing to someone who is coming in with no historical context previous attempts at working group formation. The references to "Birds of a Feather" and discussion groups make it seem like those are ways to communicate within the community but we have no process for that so this reference may also confuse folks. I recommend it be re-worded and am happy to help.
There was a problem hiding this comment.
Great suggestions @michelleN! I'm happy to work with you on it. This diagram also defines working groups in accordance with the text you referenced. It doesn't seem that vague to me, but I understand the need for explicit clarity. Let's fix this!
There was a problem hiding this comment.
Deleted this sentence for now
|
is there a TODO to add more information on disbandment? noting the title but don't see much about that in there. |
|
@parispittman As written disbandment is voluntary for whatever reason the WG decides, but the SC has implicit authority to disband the WG. Do you think we need more about the formal set of steps a WG goes through to disband? (e.g. lazy consensus)? |
|
I think so - current state leaves a lot of room for ambiguity and confusion. What if the folks leading don't want to work on it anymore and other people do? Does the group need to inform SC that they are done? |
|
Is the chair/organizer/people that started the group the ultimate decision makers for the duration? I see the note that says chairs need to make sure that the group stays on track. Wanted to ask before assuming Chairs. |
|
My concerns are addressed, and this lgtm. Paris' comments are worth addressing though. |
|
I actually don't think I fully understand what problem working groups are solving that isn't already covered today. They are supposed to have a clearly defined objective and exit criteria, but there is neither formal responsibility no accountability for them to do anything. I think that is by design - SIGs are the structure we use for things that require accountability such as code and process ownership. Since the deliverables for Working Groups are really only accounted to the WG itself, the questions about what is the problem and what is being delivered seem only to serve bootstrapping collaboration and communication - not ensuring that the objectives are delivered. What are the goals in disbanding a Working Group? Just to clean up zombie artifacts and improve visibility into the project? AFAICT - They don't have any responsibilities, so if they aren't formally disbanded nothing gets dropped. Should we rename Working Groups to Discussion Groups so it is more clear that they are just a way to foster collaboration within the community? Are there responsibilities of the Chair besides administering the slack / email / calendar? |
k8s-ci-robot
added
the
needs-rebase
|
WDYT of: |
|
SGTM
…On Thu, Oct 11, 2018 at 3:48 PM Phillip Wittrock ***@***.***> wrote:
WDYT of:
Working Groups will be disbanded if either of the following is true:
- There is no long a Chair
- (with a 4 week grace period)
- The communication channels of the Working Group have not 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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2702 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ApoAeC4nGgZAYkU-GsEvt888iJQYgESbks5uj8q0gaJpZM4W2FiW>
.
--
Quinton Hoole
quinton@hoole.biz
|
|
sgtm too |
|
PTAL |
pwittrock
force-pushed
the
wg-formation
branch
from
dc3b754
to
699174c
Compare
k8s-ci-robot
added
size/L
| 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? |
| - meeting information | ||
| - contact methods | ||
| - any sig stakeholders | ||
| - any subproject stakeholders |
There was a problem hiding this comment.
subproject here refers to those from other SIGs. right?
| - 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. |
There was a problem hiding this comment.
and relevant section in sigs.yaml should be updated to reflect that. right?
|
Reads well @pwittrock ! |
There was a problem hiding this comment.
This looks great to me! I have no problem merging this as is and I feel like this has been discussed to death. If anyone feels strongly we can take it up in a small targeted PR.
I did have a couple of comments but those are nit-picky.
Phil -- if you are ready to go let me know and I'm happy to give this an "/lgtm" or "/approve" as necessary. (I think I'm in the right OWNERS files...)
| @@ -0,0 +1,103 @@ | |||
| # Kubernetes Working Group Formation and Disbandment | |||
|
|
|||
| Draft 1.0 // Jaice Singer DuMars // June, 2018 | |||
There was a problem hiding this comment.
Not sure we want to get in the habit of having docs like this owned by folks. Perhaps to give a nod to Jaice we have a "doc history" section at the end with significant versions or references. But there is also git history.
| @@ -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 | |||
There was a problem hiding this comment.
There is a lot of overlap here. Might be good to just shrink this section and point to wg-governance.md. Wouldn't be crazy to break out our other governance things into other docs over time.
|
@jbeda +1. I'd prefer to merge this and I can follow up with a PR to address the remaining comments next week. That way if there is anything else we would like to see, folks can file their own PR to make the changes instead of blocking on me to address them while I am out. |
|
/lgtm I haven't been deeply involved but based on #2702 (comment) and @jbeda and @brendanburns approval I think we should move forward with the merge. |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cblecker, philips The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
cc @jdumars
cc @kubernetes/steering-committee