search

kubernetes / community

Kubernetes community content
Apache License 2.0
11.94k stars 5.16k forks source link

Remove `kind/design` label #5641

Closed LappleApple closed 3 years ago

LappleApple commented 3 years ago

This label isn't needed anymore.

/kind cleanup /area enhancements /sig architecture

mrbobbytables commented 3 years ago

/sig contributor-experience

mrbobbytables commented 3 years ago

/assign @nikhita @cblecker @alisondy @mrbobbytables For further thoughts

As an FYI - at least within k/k this label isn't used that much anymore with the shift to KEPs. I'm +1 for removal, @dims +1'ed the original thread in k/enhancements as well.

https://github.com/kubernetes/kubernetes/search?q=label%3Akind%2Fdesign&state=open&type=issues

nikhita commented 3 years ago

As an FYI - at least within k/k this label isn't used that much anymore with the shift to KEPs.

Agree.

There are 68 open issues in the kubernetes org with the label kind/design. Most of them are from k/k and k/kubeadm.

There are 52 open issues in the kubernetes-sigs org with the label kind/design. Looking at the issues/PRs, it looks like they can be labelled with kind/feature. Most of them are from kind, cluster-api and controller-runtime.

Before we remove the label entirely:

cc @BenTheElder @neolit123 @vincepri - in case you have any concerns with removing the kind/design label, since it's being used in kind, kubadm, cluster-api and controller-runtime.

neolit123 commented 3 years ago

i use this label on issues that require thinking, discussion and proposal docs. it can apply to bugs and features. also note that a ticket can have multiple kinds.

if you remove the kind/design label from k/k that's fine, but let's not remove it from non-k/k repo issues. repo maintainers are free to add whatever kind/*, area/* labels they want.

vincepri commented 3 years ago

We have kind/design, but also kind/proposal. We truthfully only need a single one, although I know that Controller Runtime also uses this label. cc @DirectXMan12 @alvaroaleman

The reason to have an additional label is for us to remind that we need a design document / proposal when a feature is too large to discuss in an issue.

dims commented 3 years ago

@nikhita +1 to remove kind/design from k/k

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

mrbobbytables commented 3 years ago

/remove-lifecycle stale

MadhavJivrajani commented 3 years ago

I can take this up

From the conversation, I understand that this label should only be removed from k/k and kind/feature should be added to the currently open issues and PRs in k/k that have kind/design assigned to them. Please correct me if I'm missing something, thank you 😄

MadhavJivrajani commented 3 years ago

/assign

BenTheElder commented 3 years ago

I've been tagging kind/design on issues that do not have an agreed design yet and need one, but I don't think it's been particularly effective.

BenTheElder commented 3 years ago

The KEP process is far too heavyweight for projects outside of Kubernetes but we don't yet have an easy pattern to standup a lighter process, a few projects do now anyhow, like cluster-api and minikube.

EDIT: I still think it's fair to remove this label, but I don't think the KEP process replaces it outside of k/k for the most part.

spiffxp commented 3 years ago

I would want to see a survey of which repos other than kubernetes/kubernetes use kind/design before blanket removing it from all repos

spiffxp commented 3 years ago

Given that the label sync tool doesn't allow denylisting of org-wide defaults this would be a pretty manual change today. We can do it, but I'm not sure I see urgency to land this prior to v1.23

mrbobbytables commented 3 years ago

I think the general consensus was to remove it from k/k, but leave it as an option for others subprojects.

MadhavJivrajani commented 3 years ago

Hey folks 👋🏻

As per the standing consensus, kind/design in favor of kind/feature was decided to be removed from only k/k and not the other repos. The method I hope to follow is as follows:

Relevant slack discussion can be found here.

If folks are alright with removal of kind/design from default then I can go ahead with this approach. Please let me know if I've missed anything or if this can be done in a better way within the next 2 business days 😄

cc @nikhita

nikhita commented 3 years ago

Remove kind/design and kind/feature from the default section in labels.yaml

For anyone reading this - to elaborate, this means that new repos will not automatically include the kind/design label. If a repo wants to use the label, the repo maintainers would need to explicitly opt-in by adding the repo to labels.yaml.

Add kind/design to all repos except k/k

There are a lot of repos in the @kubernetes and @kubernetes-sigs organization right now. Adding all of the existing repos to labels.yaml will blow up the (already large) file. :)

To avoid this, I think it should be sufficient to add the kind/design label (in labels.yaml) to only those repos that actively use the repo.

mrbobbytables commented 3 years ago

To avoid this, I think it should be sufficient to add the kind/design label (in labels.yaml) to only those repos that actively use the repo.

+1

MadhavJivrajani commented 3 years ago

I think we might also need to update the pull request template in k/k

spiffxp commented 3 years ago

Just so I understand the intended outcome here, is this what everyone is expecting?

This is what https://github.com/kubernetes/test-infra/pull/23011 in its current form will accomplish.

I'm not sure I see the benefit of allowing the persistent delta between source of intent and source of truth?

MadhavJivrajani commented 3 years ago

Cross posting here:

https://github.com/kubernetes/test-infra/pull/23011#pullrequestreview-724409023