search

kubevirt / community

Community content
https://kubevirt.io
46 stars 101 forks source link

community, wg, template: create wg templates #301

Open dhiller opened 4 weeks ago

dhiller commented 4 weeks ago

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:

kubevirt-bot commented 4 weeks ago

[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](https://github.com/kubevirt/community/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
dhiller commented 4 weeks ago

/cc @iholder101 @lyarwood @chandramerla

kubevirt-bot commented 4 weeks ago

@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](https://github.com/kubevirt/community/pull/301#issuecomment-2149451452): >/cc @iholder101 @lyarwood @chandramerla Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
fabiand commented 4 weeks ago

Thanks, Daniel!

dhiller commented 4 weeks ago

/cc @aburdenthehand

lyarwood commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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

vamsikrishna-siddu commented 1 week ago

Thanks @dhiller /lgtm

kubevirt-bot commented 6 days ago

@chandramerla: changing LGTM is restricted to collaborators

In response to [this](https://github.com/kubevirt/community/pull/301#pullrequestreview-2144180239): >/lgtm Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
jschintag commented 6 days ago

Thank you @dhiller.

From s390x side /lgtm

zhlhahaha commented 6 days ago

/lgtm From Arm side, thanks @dhiller

dhiller commented 5 days ago

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

dhiller commented 5 days ago

@lyarwood thanks for the review, updated, PTAL!

lyarwood commented 5 days ago

/lgtm

kubevirt-bot commented 8 hours ago

New changes are detected. LGTM label has been removed.