search

kubevirt / community

Community content
https://kubevirt.io
50 stars 103 forks source link

proposal for new committee `code-quality` #327

Open dhiller opened 1 week ago

dhiller commented 1 week ago

Is your feature request related to a problem? Please describe: As pointed out in https://github.com/kubevirt/project-infra/pull/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 neither make sense to build a SIG nor a WG on that matter.

Describe the solution you'd like: K8s community has another form of organized group called "committee" which might be sufficiently loose enough to cover this case.

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

Additional context: References:

iholder101 commented 4 days ago

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: https://github.com/kubevirt/community/pull/296.

EdDev commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

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 commented 1 day ago

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 commented 1 day ago

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 commented 1 day ago

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

lyarwood commented 1 day ago

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.