Working Groups - Definition and template

[Daniel Hiller]

Hey all,

since the initial PR [1] covering the introduction of wg-arch-* it became clear there is a need around a general definition and differentiation of WGs vs. SIGs.

Therefore I split out the changes covering descriptions for SIGs and WGs and wg-templates into another PR [2]

Thanks Itamar, Lee and Or for chiming in already, others please chime in as needed.

[2] https://github.com/kubevirt/community/pull/301 

[1] https://github.com/kubevirt/community/pull/298
--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com   

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

[Lee Yarwood]

On Wed, 5 Jun 2024 at 12:45, Daniel Hiller <dhi...@redhat.com> wrote:
>
> Hey all,
>
> since the initial PR [1] covering the introduction of wg-arch-* it became clear there is a need around a general definition and differentiation of WGs vs. SIGs.
>
> Therefore I split out the changes covering descriptions for SIGs and WGs and wg-templates into another PR [2]
>
> Thanks Itamar, Lee and Or for chiming in already, others please chime in as needed.
>
> [2] https://github.com/kubevirt/community/pull/301
> [1] https://github.com/kubevirt/community/pull/298

Thanks Daniel,

As discussed I'm against redefining the meaning of a WG within
KubeVirt and would prefer to use the existing k8s definition.

I've set this out in your initial PR [1], the wg/ipam [3] PR and my
own sig-compute instance types subproject PRs [4][5], feedback from
the wider community would definitely be appreciated here as I don't
feel like this is a popular suggestion at present and don't want to
waste time if the majority want to go in a different direction.

Cheers,

Lee

[3] https://github.com/kubevirt/kubevirt/pull/12058
[4] https://github.com/kubevirt/kubevirt/pull/12062
[5] https://github.com/kubevirt/community/pull/302

[Felix Matouschek]

Hey all,

Am Mittwoch, dem 05.06.2024 um 18:19 +0100 schrieb Lee Yarwood:
> As discussed I'm against redefining the meaning of a WG within
> KubeVirt and would prefer to use the existing k8s definition.
>
> I've set this out in your initial PR [1], the wg/ipam [3] PR and my
> own sig-compute instance types subproject PRs [4][5], feedback from
> the wider community would definitely be appreciated here as I don't
> feel like this is a popular suggestion at present and don't want to
> waste time if the majority want to go in a different direction.
>
> Cheers,
>
> Lee
>
> [3] https://github.com/kubevirt/kubevirt/pull/12058
> [4] https://github.com/kubevirt/kubevirt/pull/12062
> [5] https://github.com/kubevirt/community/pull/302
>

as Lee suggested, I would also prefer to stick to the definition of a
WG provided by Kubernetes instead of coming up with our own definition.

I would argue that the proximity to Kubernetes makes it easier to keep
track and to attract new contributors.

Thanks,
Felix

[Daniel Hiller]

Hey Lee,

On Wed, Jun 5, 2024 at 7:19 PM Lee Yarwood <lyar...@redhat.com> wrote:

On Wed, 5 Jun 2024 at 12:45, Daniel Hiller <dhi...@redhat.com> wrote:
>
> Hey all,
>
> since the initial PR [1] covering the introduction of wg-arch-* it became clear there is a need around a general definition and differentiation of WGs vs. SIGs.
>
> Therefore I split out the changes covering descriptions for SIGs and WGs and wg-templates into another PR [2]
>
> Thanks Itamar, Lee and Or for chiming in already, others please chime in as needed.
>
> [2] https://github.com/kubevirt/community/pull/301
> [1] https://github.com/kubevirt/community/pull/298

Thanks Daniel,

As discussed I'm against redefining the meaning of a WG within
KubeVirt and would prefer to use the existing k8s definition.

I've set this out in your initial PR [1], the wg/ipam [3] PR and my
own sig-compute instance types subproject PRs [4][5], feedback from
the wider community would definitely be appreciated here as I don't
feel like this is a popular suggestion at present and don't want to
waste time if the majority want to go in a different direction.

Thank you for your thoughts on this.

FWIW wrt wg-arch-* we are trying to solve an ownership issue. Someone has to own (aka take responsibility  for) the node architecture specific topics. There's lots of things beyond code that are to be owned - take for example the arm clusters that Howard provided and maintains. I am not saying that there's (also) code that needs to be owned, and I think the subproject approach that you suggest is a great idea. In the end someone needs to own that obviously. And I think that if needed for arch matters, there will be subprojects formed in the SIGs where people take the responsibility to own the code - but currently I think it is pretty hard to make dedicated claims about code portions belonging to specific node architectures - please keep me honest here, folks.

I think we would be left in a bad situation if we actually had people that would establish support for a specific architecture, and then the group of people would disband. In the worst case there'd be noone left that would be assisting the user base in fixing problems. All I am trying to solve here is continuous ownership of all the related matters, which as I said, touches multiple SIGs responsibilities.

Now that I've read the comments, I tend to agree that redefining a WG should not happen - I will go and link the explanations to the k8s definitions.

What is still left to be solved is how we can avoid the situation I've described above - happy to hear everyone's thoughts about this.

 

Cheers,

Lee

[3] https://github.com/kubevirt/kubevirt/pull/12058
[4] https://github.com/kubevirt/kubevirt/pull/12062
[5] https://github.com/kubevirt/community/pull/302

--

-- 

Best,

Daniel

[Lee Yarwood]

On Thu, 6 Jun 2024 at 10:30, Daniel Hiller <dhi...@redhat.com> wrote:
> On Wed, Jun 5, 2024 at 7:19 PM Lee Yarwood <lyar...@redhat.com> wrote:
>> On Wed, 5 Jun 2024 at 12:45, Daniel Hiller <dhi...@redhat.com> wrote:
>> >
>> > Hey all,
>> >
>> > since the initial PR [1] covering the introduction of wg-arch-* it became clear there is a need around a general definition and differentiation of WGs vs. SIGs.
>> >
>> > Therefore I split out the changes covering descriptions for SIGs and WGs and wg-templates into another PR [2]
>> >
>> > Thanks Itamar, Lee and Or for chiming in already, others please chime in as needed.
>> >
>> > [2] https://github.com/kubevirt/community/pull/301
>> > [1] https://github.com/kubevirt/community/pull/298
>>
>> Thanks Daniel,
>>
>> As discussed I'm against redefining the meaning of a WG within
>> KubeVirt and would prefer to use the existing k8s definition.
>>
>> I've set this out in your initial PR [1], the wg/ipam [3] PR and my
>> own sig-compute instance types subproject PRs [4][5], feedback from
>> the wider community would definitely be appreciated here as I don't
>> feel like this is a popular suggestion at present and don't want to
>> waste time if the majority want to go in a different direction.
>
>
> Thank you for your thoughts on this.
>
> FWIW wrt wg-arch-* we are trying to solve an ownership issue. Someone has to own (aka take responsibility for) the node architecture specific topics.
> There's lots of things beyond code that are to be owned - take for example the arm clusters that Howard provided and maintains. I am not saying that
> there's (also) code that needs to be owned, and I think the subproject approach that you suggest is a great idea. In the end someone needs to own that obviously.

Okay how about something like:

- 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

> And I think that if needed for arch matters, there will be subprojects formed in the SIGs where people take the responsibility to own the code - but currently I think it is pretty hard to make dedicated claims about code portions belonging to specific node architectures - please keep me honest here, folks.

That would just require refactoring the code to allow this and
shouldn't be a blocker IMHO.

> I think we would be left in a bad situation if we actually had people that would establish support for a specific architecture, and then the group of people would disband. In the worst case there'd be noone left that would be assisting the user base in fixing problems. All I am trying to solve here is continuous ownership of all the related matters, which as I said, touches multiple SIGs responsibilities.

Yup agreed, hopefully the subproject structure I've suggested above
would facilitate this.

> Now that I've read the comments, I tend to agree that redefining a WG should not happen - I will go and link the explanations to the k8s definitions.

Excellent thanks :)

> What is still left to be solved is how we can avoid the situation I've described above - happy to hear everyone's thoughts about this.

Hopefully the above helps.

Lee

[Daniel Hiller]

Hey all,

I've restructured both the wg-template [1] and the wg-arch [2] PRs - honestly, I've been struggling a bit, so I removed everything that I don't deem required currently. 

Basically I've created one WG per arch, and added subprojects to sig-buildsystem and sig-ci, so that people can own code.

Please take note of the following refinements to be done in follow ups:

* the actual role definitions don't make that much sense, as being chair and lead in two subprojects is a bit much to ask

* I've only included owners references in subprojects for the main project folders

* the creation of subproject groups inside OWNERS_ALIASES in the related projects

The latter I deem is based on the feedback from the community PRs, so I am waiting to do this until the feedback is incorporated.

[1] https://github.com/kubevirt/community/pull/301

[2] https://github.com/kubevirt/community/pull/298

 

> And I think that if needed for arch matters, there will be subprojects formed in the SIGs where people take the responsibility to own the code - but currently I think it is pretty hard to make dedicated claims about code portions belonging to specific node architectures - please keep me honest here, folks.

That would just require refactoring the code to allow this and
shouldn't be a blocker IMHO.

> I think we would be left in a bad situation if we actually had people that would establish support for a specific architecture, and then the group of people would disband. In the worst case there'd be noone left that would be assisting the user base in fixing problems. All I am trying to solve here is continuous ownership of all the related matters, which as I said, touches multiple SIGs responsibilities.

Yup agreed, hopefully the subproject structure I've suggested above
would facilitate this.

> Now that I've read the comments, I tend to agree that redefining a WG should not happen - I will go and link the explanations to the k8s definitions.

Excellent thanks :)

> What is still left to be solved is how we can avoid the situation I've described above - happy to hear everyone's thoughts about this.

Hopefully the above helps.

Lee

--

-- 

Best,

Daniel

[Daniel Hiller]

Hey,

so far I've been missing a bit of feedback from the groundwork for working groups PR [1].

@Andrew Burden @Fabian Deutsch would you be able to chime in on this?

[1] https://github.com/kubevirt/community/pull/301

--

-- 

Best,

Daniel