community, wg, template: create wg templates #301
Conversation
kubevirt-bot
added
the
dco-signoff: yes
|
@dhiller: GitHub didn't allow me to request PR reviews from the following users: chandramerla. Note that only kubevirt members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Thanks, Daniel! |
|
/cc @aburdenthehand |
SIGS_AND_WGS.md
Outdated
|
|
||
| ## WG | ||
|
|
||
| A **WG (Working Group)** is a group of people that owns a more specific topic within the project, possibly touching the scope of more than one SIG, with whom the WG interacts. |
There was a problem hiding this comment.
I'm against redefining the k8s meaning of a WG here by suggesting that ownership is possible outside of a SIG [1][2].
As I've suggested elsewhere [3] we can avoid this by just using subprojects within a SIG [4] and keep the k8s definition of a WG to be a multi SIG collaboration vehicle.
[1] https://github.com/kubernetes/community/blob/master/governance.md#working-groups
[2] https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md#is-it-a-working-group-yes-if
[3] #299 (comment)
[4] https://github.com/kubernetes/community/blob/master/governance.md#subprojects
There was a problem hiding this comment.
@lyarwood in Kubernetes WGs are short-lived, and I don't think that this serves node architecture related matters well (for which the initial PR was created), since for that matter clearly an ownership needs to exist in the longer term.
Therefore I have refrained from copying the k8s definitions.
Aside of that I am not talking about specific code ownership here (I agree that this is restricted to SIGs IMHO), but rather about topic ownership. Maybe since I am not a native speaker this is just a matter of words, so I could use some advice about how to rephrase it.
There was a problem hiding this comment.
@dhiller processes and deliverables are all also ultimately owned by a SIG within k8s thus my suggestion again to use a SIG sub project instead of redefining the k8s WG definition. These sub projects also have leads and owners so should accommodate what you want to achieve in #298. I'm working through an example for instance types under SIG Compute within kubevirt/kubevirt#12062 and #302 FWIW.
There was a problem hiding this comment.
First of all: what is the problem with redefining WGs for KubeVirt?
Second: Actually, when looking at the document you provided, the sense of the above sentence isn't even redefining it, but rather just avoiding the phrase "short-lived", no?
In that way, and also looking at the document, I think that working group is perfectly right for node architecture, since it actually spans multiple SIGs.
And the sentence explicitly says "owns a more specific topic" and says nothing about code ownership, so again - what is wrong with that sentence?
Please help, thanks :)
There was a problem hiding this comment.
First of all: what is the problem with redefining WGs for KubeVirt?
I just don't understand why it's required when the existing and well understood (at least across CNCF) definitions of k8s provide everything we need IMHO.
Second: Actually, when looking at the document you provided, the sense of the above sentence isn't even redefining it, but rather just avoiding the phrase "short-lived", no?
That and suggesting ownership of a topic instead of being targeted at resolving a specific problem.
In that way, and also looking at the document, I think that working group is perfectly right for node architecture, since it actually spans multiple SIGs.
They definitely are for organising around a defined problem like initially standing up a new architecture across multiple SIGs yes but the on-going ownership of the topic, processes and deliverables should still reside in a SIG IMHO with specific architectures listed as sub projects.
And the sentence explicitly says "owns a more specific topic" and says nothing about code ownership, so again - what is wrong with that sentence?
As I tried to say before SIGs own more than just code and WGs in k8s own nothing.
Please help, thanks :)
FWIW I've not received any positive feedback on my stance here or in other PRs so it's likely that I'm standing alone on this hill.
There was a problem hiding this comment.
IIUC the original reasoning to introduce the WG concept originated from the need to formalize code ownership of smaller scoped groups (than SIGs).
After @lyarwood clarified the difference between a WG and a subproject, the original reasoning is lost.
IMO there is a need to clarify the new reasoning to establish WG in Kubevirt with examples to such groups that are needed.
At the moment, I’m not familiar with a group of members that meet and discuss cross-SIG topics (that is not owned by a specific SIG). Is there something like this?
On the other hand, the original need for a more granular code ownership is still needed. In that regard, I agree with @lyarwood that we need to define subprojects in Kubevirt.
I posted a suggestion on the ML about this yesterday using SIG sub projects for ownership and WGs to drive standing up each architecture across other SIGs: https://groups.google.com/g/kubevirt-dev/c/G6eCHpxJ9DU/m/PaeGjNSaAAAJ
I might be overthinking things at this point but if we do need WGs going forward then this pattern could work.
Thanks :) |
I see, thank you for the ref. |
|
@EdDev @lyarwood I see this PR as a ground work on which the actual folks from which we require responsibilities wrt code and infra can build upon. Therefore I've kept this pretty vague by intention. @lyarwood I don't want to take the decision from the folks inside the arch teams for S390X or ARM how they organize themselves- I think that is a decision to be taken by them; in claiming the responsibility by joining a WG and assigning subsets of code to subproject What I would want to hear from folks @jschintag @cfilleke @vamsikrishna-siddu @zhlhahaha and others is how they are going to organize themselves in keeping the responsibilities that can be seen around arch work. We might then adjust the follow up PR as needed - this one I think might be left as is currently... WDYT? |
There was a problem hiding this comment.
@EdDev @lyarwood I see this PR as a ground work on which the actual folks from which we require responsibilities wrt code and infra can build upon. Therefore I've kept this pretty vague by intention.
@lyarwood I don't want to take the decision from the folks inside the arch teams for S390X or ARM how they organize themselves- I think that is a decision to be taken by them; in claiming the responsibility by joining a WG and assigning subsets of code to subproject
sig-buildsystem-arch-*.
ACK understood.
/lgtm
What I would want to hear from folks @jschintag @cfilleke @vamsikrishna-siddu @zhlhahaha and others is how they are going to organize themselves in keeping the responsibilities that can be seen around arch work. We might then adjust the follow up PR as needed - this one I think might be left as is currently...
WDYT?
+1
Signed-off-by: Daniel Hiller <[email protected]>
Create a template for working group definitions, aligned to how SIG templates currently look. Signed-off-by: Daniel Hiller <[email protected]>
Fix whitespace, link to membership policy instead. Co-authored-by: aburdenthehand <[email protected]> Signed-off-by: Daniel Hiller <[email protected]>
Co-authored-by: aburdenthehand <[email protected]> Signed-off-by: Daniel Hiller <[email protected]>
Also add two example GitHub handles under chairs to make clear that two are the minimum. Signed-off-by: Daniel Hiller <[email protected]>
@aburdenthehand thank you for your review, I've addressed the comments. PTAL! |
|
/lgtm |
|
This PR is waiting for three weeks now. Hey @cwilkers @davidvossel @fabiand @rmohr @vladikr 👋 Since @aburdenthehand is out for a while, is one of you able to take a quick look and approve this? |
|
Pull requests that are marked with After that period the bot marks them with the label /label needs-approver-review |
|
@kubevirt-bot: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
dhiller
added
the
needs-approver-review
|
@jean-edouard did you have a chance to go over this PR? |
@dhiller are WGs still something we're considering? |
@jean-edouard this PR only does groundwork, i.e. laying out the structure for contributors who want to organize inside a working group, in cases where a SIG does not fit. IMHO this is necessary so that contributors know how we think governance inside KubeVirt org works - and I believe that a defined governance process is also a requirement for the graduation of KubeVirt, see #307. Please note that this PR does not define any WG by itself - although I did create a PR for WG arches to test out how an example WG might look like. |
|
Thanks @dhiller ! |
kubevirt-bot
added
the
approved
|
|
||
| ## Goals | ||
|
|
||
| The primary goal of the charters is to define the scope of the WG within KubeVirt and how the WG can determine whether it has achieved their solution. A majority of the effort should be spent on these concerns. |
There was a problem hiding this comment.
| The primary goal of the charters is to define the scope of the WG within KubeVirt and how the WG can determine whether it has achieved their solution. A majority of the effort should be spent on these concerns. | |
| The primary goal of the charters is to define the scope of the WG within KubeVirt and how the WG can determine whether it has reached its goal(s). Most of the effort should be spent on these concerns. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jean-edouard, vladikr 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 |
|
/remove-label needs-approver-review |
kubevirt-bot
removed
the
needs-approver-review
What this PR does / why we need it:
This PR:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
/cc @oshoval @fabiand
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.
Release note: