kubevirt, labels: rename code-quality into cleanup

[dhiller]

What this PR does / why we need it:

The label sig/code-quality is used to mark pull requests that target improvements to our code base1. However, the prefix sig gives the impression that there is a SIG that is actively caring for such PRs.

Given the fact that there's neither an entry inside sigs.yaml2, nor a proper sig folder in the community repository, nor any publicly held meetings that are announced in the community calendar3, we can assume that such a sig doesn't exist.

During the discussion at the community meeting4 about this topic there was the suggestion to just rename the label into a kind label. Looking at Kubernetes labels provided a general label kind/cleanup5 that matches a broader set of scenarios and seems to be well suited for covering all the code-quality PRs.

Therefore this PR renames the label sig/code-quality to kind/cleanup.

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:

[dhiller]

/cc @enp0s3 @xpivarc @iholder101 @stu-gott

[dankenigsberg]

Thanks for noticing this, @dhiller. However, maybe the problem can be fixed by nominating a sig chair and setting up a recurring meeting or anything else that would satisfy the sig requirements? I don't really know if it's better, but wonder if it makes sense to others.

[iholder101]

Thanks for noticing this, @dhiller. However, maybe the problem can be fixed by nominating a sig chair and setting up a recurring meeting or anything else that would satisfy the sig requirements? I don't really know if it's better, but wonder if it makes sense to others.

Hey @dankenigsberg!

Code quality is an important topic. However, as discussed in the community meeting, while I think that setting up a recurring meeting to promote it makes sense, I think that it doesn't suit to be a SIG.

The purpose of SIGs is to divide the project into manageable parts, each with its own area of responsibility. Code quality, however, is a concern that spans across all SIGs rather than being confined to a single, self-contained unit. For example, I don't see any feature or a design proposal being owned by this SIG.

Another alternative that was discussed in the community meeting is a working group, but the problem with it is that it's usually time-bound while improving code quality is an ever lasting task.

I'm happy to discuss alternatives, but kind/cleanup sounds good to me. We can still set up a recurring meeting if we think that's valuable.

[dhiller]

Thanks for noticing this, @dhiller. However, maybe the problem can be fixed by nominating a sig chair and setting up a recurring meeting or anything else that would satisfy the sig requirements? I don't really know if it's better, but wonder if it makes sense to others.

Hey @dankenigsberg!

Code quality is an important topic. However, as discussed in the community meeting, while I think that setting up a recurring meeting to promote it makes sense, I think that it doesn't suit to be a SIG.

The purpose of SIGs is to divide the project into manageable parts, each with its own area of responsibility. Code quality, however, is a concern that spans across all SIGs rather than being confined to a single, self-contained unit. For example, I don't see any feature or a design proposal being owned by this SIG.

Another alternative that was discussed in the community meeting is a working group, but the problem with it is that it's usually time-bound while improving code quality is an ever lasting task.

I'm happy to discuss alternatives, but kind/cleanup sounds good to me. We can still set up a recurring meeting if we think that's valuable.

+1 to what @iholder101 said.

[dhiller]

See also

• https://github.com/kubevirt/community/pull/301
• https://github.com/kubevirt/community/pull/306

[iholder101]

Therefore this PR renames the label sig/code-quality to kind/cleanup.

To clarify: will this PR rename labels on existing/past PRs as well? Should we do that?

[dhiller]

Therefore this PR renames the label sig/code-quality to kind/cleanup.

To clarify: will this PR rename labels on existing/past PRs as well? Should we do that?

Yes, the label_sync 1 tool, which we are using to converge our GitHub label configuration with on a periodic basis, will migrate the GitHub label.

The previously section we added here 2 will indicate that it should be migrated.

[dhiller]

Thanks for noticing this, @dhiller. However, maybe the problem can be fixed by nominating a sig chair and setting up a recurring meeting or anything else that would satisfy the sig requirements? I don't really know if it's better, but wonder if it makes sense to others.

Hey @dankenigsberg!

Code quality is an important topic. However, as discussed in the community meeting, while I think that setting up a recurring meeting to promote it makes sense, I think that it doesn't suit to be a SIG.

The purpose of SIGs is to divide the project into manageable parts, each with its own area of responsibility. Code quality, however, is a concern that spans across all SIGs rather than being confined to a single, self-contained unit. For example, I don't see any feature or a design proposal being owned by this SIG.

Another alternative that was discussed in the community meeting is a working group, but the problem with it is that it's usually time-bound while improving code quality is an ever lasting task.

I'm happy to discuss alternatives, but kind/cleanup sounds good to me. We can still set up a recurring meeting if we think that's valuable.

do you have people in mind that would be interested in pursuing this - since, as @iholder101 also noted, sig and wg are not a good fit, we might try doing this as a committee?

Aside from that: are you ok with renaming this label - I think that kind/cleanup fits more opportunities than only code-quality. WDYT?

[dankenigsberg]

sorry for being unclear @dhiller . I'm not holding this PR.

[dhiller]

So, in order to move this forward, I'm pinging

@iholder101

who seemed to be in favor of this and

/cc @brianmcarey

as an approver.

[iholder101]

As said above, I am in favor of this. While I don't think code-quality should be a SIG, I definitely think it's an important topic and would support an upstream interest group of some other constellation in order to continuously promote it.

Thank you @dhiller!

/lgtm

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brianmcarey

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [brianmcarey]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[kubevirt-bot]

@dhiller: Updated the label-config configmap in namespace kubevirt-prow at cluster default using the following files:

• key labels.yaml using file github/ci/prow-deploy/kustom/base/configs/current/labels/labels.yaml

In response to this:

What this PR does / why we need it:

The label sig/code-quality is used to mark pull requests that target improvements to our code base1. However, the prefix sig gives the impression that there is a SIG that is actively caring for such PRs.

Given the fact that there's neither an entry inside sigs.yaml2, nor a proper sig folder in the community repository, nor any publicly held meetings that are announced in the community calendar3, we can assume that such a sig doesn't exist.

During the discussion at the community meeting4 about this topic there was the suggestion to just rename the label into a kind label. Looking at Kubernetes labels provided a general label kind/cleanup5 that matches a broader set of scenarios and seems to be well suited for covering all the code-quality PRs.

Therefore this PR renames the label sig/code-quality to kind/cleanup.

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:

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.

[EdDev]

I'm sorry, but IMO this should have received a wider agreement before letting it in.

In fact, it should have been accepted only after a format for the effort was set and not before.

[brianmcarey]

I'm sorry, but IMO this should have received a wider agreement before letting it in.

The same could of been said for the initial introduction of the sig-code-quality label - I couldn't find anything on the mailing list introducing the new label.

In fact, it should have been accepted only after a format for the effort was set and not before.

The fact that there was no formal SIG Code Quality meant that the existing label was wrong and misleading.

[EdDev]

I'm sorry, but IMO this should have received a wider agreement before letting it in.

The same could of been said for the initial introduction of the sig-code-quality label - I couldn't find anything on the mailing list introducing the new label.

I agree, it was a mistake.

In fact, it should have been accepted only after a format for the effort was set and not before.

The fact that there was no formal SIG Code Quality meant that the existing label was wrong and misleading.

I agree as well. But changing it now after it was used extensively needs to be done once and not prematurely like we have done when we introduced it.

[brianmcarey]

I'm sorry, but IMO this should have received a wider agreement before letting it in.

The same could of been said for the initial introduction of the sig-code-quality label - I couldn't find anything on the mailing list introducing the new label.

I agree, it was a mistake.

In fact, it should have been accepted only after a format for the effort was set and not before.

The fact that there was no formal SIG Code Quality meant that the existing label was wrong and misleading.

I agree as well. But changing it now after it was used extensively needs to be done once and not prematurely like we have done when we introduced it.

+1.

kind/cleanup is a generic enough placeholder while we are waiting for the outcome of the community proposal around the code quality initiative - I think it should be ok.