community
community copied to clipboard
kubevirt
community, wg, template: create wg templates
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:
@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.
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 :)
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.
@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?
@chandramerla: changing LGTM is restricted to collaborators
In response to this:
/lgtm
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.
@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!
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!
This PR is waiting for three weeks now.
Hey @cwilkers @davidvossel @fabiand @rmohr @vladikr :wave:
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 lgtm should receive a review
from an approver within 1 week.
After that period the bot marks them with the label needs-approver-review.
/label needs-approver-review
@kubevirt-bot: The label(s) needs-approver-review cannot be applied, because the repository doesn't have them.
In response to this:
Pull requests that are marked with
lgtmshould receive a review from an approver within 1 week.After that period the bot marks them with the label
needs-approver-review./label needs-approver-review
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.
@jean-edouard did you have a chance to go over this PR?
@dhiller are WGs still something we're considering?
@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 https://github.com/kubevirt/community/issues/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.
[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
- ~~OWNERS~~ [jean-edouard,vladikr]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment