community, wg, template: create wg templates

[dhiller]

What this PR does / why we need it:

This PR:

• updates the document GOVERNANCE.md that describes SIGs and WGs.
• creates a template for working group definitions, aligned to how SIG templates currently look.

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.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign cwilkers for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dhiller]

/cc @iholder101 @lyarwood @chandramerla

[kubevirt-bot]

@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:

/cc @iholder101 @lyarwood @chandramerla

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.

[fabiand]

Thanks, Daniel!

[dhiller]

/cc @aburdenthehand

[lyarwood]

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

[dhiller]

@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.

[lyarwood]

@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.

[dhiller]

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 :)

[lyarwood]

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.

[lyarwood]

Looks good, I'd still like to drop the Code, Binaries and Services section and just leave the generic in and out of scope parts.

[EdDev]

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.

[lyarwood]

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?

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

• A subproject per arch under SIG buildsystem to own the build aspect
  but also the infra associated with building, testing etc.
• A working group per arch ran by the SIG buildsystem subproject team
  with the aim of handling the cross SIG collaboration required to stand
  up support for said arch
• Additional subprojects per arch in any SIG where it's required to
  own specific logic, I could see this being useful in SIG compute for
  example to handle arch specific logic

I might be overthinking things at this point but if we do need WGs going forward then this pattern could work.

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.

Thanks :)

[EdDev]

WGs to drive standing up each architecture across other SIGs

I see, thank you for the ref.
It will be useful to evaluate this after experiencing the actual work efforts.

[dhiller]

@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-*.

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?

[lyarwood]

@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

[dhiller]

@aburdenthehand @EdDev what you said makes sense - I've restructured the GOVERNANCE.md to include the paragraphs about SIGS, subprojects and WGs, also I've added a subset of the descriptions to each paragraph, and added links to k8s resources about the topics.

PTAL, thank you all for your feedback!

[lyarwood]

Thanks @dhiller this looks great, just a few simple nits.

[dhiller]

@lyarwood thanks for the review, updated, PTAL!

[lyarwood]

/lgtm

[aburdenthehand]

Great stuff @dhiller :D
Thanks for putting all this together. I have a question to consider and a teensy tiny nit.

[aburdenthehand]

Great stuff. I have no complaints and am really happy to see this.
I've suggested a couple of changes in the templates

[dhiller]

Great stuff. I have no complaints and am really happy to see this. I've suggested a couple of changes in the templates

@aburdenthehand thank you for your review, I've addressed the comments. PTAL!

[aburdenthehand]

/lgtm

[dhiller]

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?