[Tracking Issue] `kind/design` to `kind/feature` migration cleanup

[MadhavJivrajani]

Following up from the communication that was sent out regarding the migration of kind/design to kind/feature and the changes that would entail - this issue is for tracking the cleanup work that needs to be done for completing that migration.

The next step is to actually remove the label from the GitHub repos that did not opt-in for the kind/design label (see the above linked communication for more details), removing the label from the repo entails two main things:

• First, remove kind/design from all open issues and PRs in said repo
• Second, after no open issue/PR has this label anymore, remove it from the repository itself.

Currently, the following issues have the kind/design on open issues/PRs:

• kubernetes: 26 (note that kubeadm is an opt-in repo) (26 open are all kubeadm)
• kubernets-sigs: 27 (note that k-sigs/cluster-api and `k-sigs/controller-runtime are opt-in repos)
• kubernetes-client: 0
• kubernetes-csi: 0
• kubernetes-security: 0

/sig contributor-experience /area github-management /assign @nikhita

[BenTheElder]

Er, these other repos are not supposed to have the label removed, please re-read the communication in https://groups.google.com/g/kubernetes-dev/c/f6W68eS8xo0

[MadhavJivrajani]

Hey @BenTheElder, first off - apologies for the spam! :/

Secondly - the email states that only if folks opt-in (either by replying in the email thread within the lazy consensus period, or additionally opening up a PR to test-infra as layed out or have opted-in in the original issue), only then would kind/design remain for those repositories (and so far the only repositories that are counted as opted-in are k/kubeadm, k-sig/{controller-runtime, cluster-api}. And non-response would be counted as opting out, and hence subsequent removal.

The manual removal was discussed with github-managment and it turned out to be the path of least resistance (albeit a little noisy).

[BenTheElder]

I see, I apologize, I thought kind was already in the opted list. At this point given there only appear to be two open issues, we might as well let it go. TBQH I have had less time to triage there anyhow and I don't think others have expressed opinions one way or another about the labels. cc @aojea

[BenTheElder]

In the future I do think we should have a bot remove the label for changes like this: for repos using the fejta-bot auto close process (which I dislike and don't use but ...) commenting alters the last-updated time but label removal itself does not.

It also makes the action more impersonal, which I think we should generally do for process changes, to avoid responses being or appearing to be aimed at an individual rather than the process / robot 🙃

Thanks for working to clean up our repos! :-)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[MadhavJivrajani]

/remove-lifecyle stale /lifecycle frozen

[mrbobbytables]

@MadhavJivrajani I think all the follow up items are done? Are we safe to close?

[MadhavJivrajani]

Hey @mrbobbytables, thanks for the ping. There are a few items left, namely cleanup from the k-sigs org, and more importantly - actually deleting the kind/design label from these repositories (would need a gh admin to do that).