proposal for new WG code-quality

[dhiller]

Is your feature request related to a problem? Please describe:
As pointed out in kubevirt/project-infra#3614 there's currently no public approachable group in existence related to code-quality 1

However, it would make sense to build such a group, since there obviously is an interest in the topic of code-quality, as there's 20+ issues and 400+ pull requests with that label (see query below). In general there's people required to steer that effort by making general decisions about topics long term goals and guidelines.

As discussed in the community meeting and on mentioned PR, it does not make sense to build a SIG. Also a committee does not have to operate in the open and has a closed membership.

Describe the solution you'd like:
The proposal 2 is to create a WG that has the goal of

• short-term focus on the improvement of code quality and
• long-term create an inter-SIG process for identifying, agreeing on and addressing code quality issues

Describe alternatives you've considered:
A clear and concise description of any alternative solutions or features you've considered.

Additional context:
References:

• kubevirt, labels: rename code-quality into cleanup project-infra#3614 (comment)
• kubevirt, labels: rename code-quality into cleanup project-infra#3614 (comment)
• GitHub search results for label:kind/cleanup (was: label:sig/code-quality)

[iholder101]

Thank you @dhiller! Looks good to me.

I think that such a committee might be a good alternative for the suggested yet controversial sig-api here: #296.

[EdDev]

I think that such a committee might be a good alternative for the suggested yet controversial sig-api here: #296.

I disagree. That effort has nothing to do with code-quality and everything to do with having a good and stable formal API.

[EdDev]

As discussed in the community meeting and on mentioned PR, it does neither make sense to build a SIG nor a WG on that matter.

Can you please summarize here what was the result of that discussion?
I agree that code-quality is not a SIG, but I do not understand why it is not a WG.

[iholder101]

I think that such a committee might be a good alternative for the suggested yet controversial sig-api here: #296.

I disagree. That effort has nothing to do with code-quality and everything to do with having a good and stable formal API.

I meant that IMO a committee is better to discuss good and stable API than a SIG.

[lyarwood]

Can you please summarize here what was the result of that discussion?
I agree that code-quality is not a SIG, but I do not understand why it is not a WG.

https://github.com/kubevirt/community/blob/main/GOVERNANCE.md#working-groups

Yeah also think this could be a WG as it's cross SIG etc.

It would be great to have an upstream group defined for this outside of the much appreciated but localised downstream group currently leading this effort!

[dhiller]

Can you please summarize here what was the result of that discussion?
I agree that code-quality is not a SIG, but I do not understand why it is not a WG.

main/GOVERNANCE.md#working-groups

Yeah also think this could be a WG as it's cross SIG etc.

It would be great to have an upstream group defined for this outside of the much appreciated but localised downstream group currently leading this effort!

K8s WGs are time bound and will be disbanded after the goal has been achieved 1. To my understanding we want to follow what Kubernetes does.

Since improving code quality is an ongoing process, this contradicts with formation of WGs.

[dhiller]

@dosu please explain what criterias for Kubernetes Working Groups are.

[lyarwood]

K8s WGs are time bound and will be disbanded after the goal has been achieved 1. To my understanding we want to follow what Kubernetes does.

Since improving code quality is an ongoing process, this contradicts with formation of WGs.

I appreciate that but by definition k8s committees also have closed membership and do not have to operate in the open.

I think a WG focused on the short term improvement of code quality and on defining a longer term inter-SIG process for identifying, agreeing on and addressing code quality issues is perfectly acceptable. Once such a process is in place the WG can disband and the SIGs can take over improving code quality within their respected parts of the codebase.

[dhiller]

K8s WGs are time bound and will be disbanded after the goal has been achieved 1. To my understanding we want to follow what Kubernetes does.
Since improving code quality is an ongoing process, this contradicts with formation of WGs.

I appreciate that but by definition k8s committees also have closed membership and do not have to operate in the open.

I think a WG focused on the short term improvement of code quality and on defining a longer term inter-SIG process for identifying, agreeing on and addressing code quality issues is perfectly acceptable. Once such a process is in place the WG can disband and the SIGs can take over improving code quality within their respected parts of the codebase.

Makes sense.

@0xFelix @iholder101 @fossedihelm pinging you for awareness.

/assign

I'll take the task of creating a PR to propose something - or any other takers?

[dhiller]

@lyarwood updated the issue description, please chime in if you disagree

[lyarwood]

@lyarwood updated the issue description, please chime in if you disagree

That's excellent thanks @dhiller!

[iholder101]

Thanks @dhiller and @lyarwood!

I'm not sure why a WG is better than a committee TBH, but I don't feel strongly about it.
I also still think that we should use a WG/committee for the "sig-api" effort.

[0xFelix]

@dhiller Looks good to me! Thanks

Will this WG have some sort of regular meetings or a channel / forum to discuss topics in? How should we organize it?

[dhiller]

• short-term focus on the improvement of code quality and
• long-term create an inter-SIG process for identifying, agreeing on and addressing code quality issues

@0xFelix good point - I have added this as a topic to our community meeting agenda