TL;DR - The kind/design label will now be an opt-in label for all existing and newly created repositories. Please reply to this email if you are a maintainer of a repository that currently actively uses kind/design or would like to start using kind/design. Please read further for more details on this. The lazy consensus period ends on 27th September.
Due to the adoption of KEPs as a replacement to design proposals in kubernetes/kubernetes, the kind/design label will be migrated to the kind/feature label . Please read the consequences of the same and what it means for you if you are a maintainer of a repository that actively uses the kind/design label.
After implementing this migration , kind/design will be an opt-in label. This means that any existing repository which actively uses kind/design or a newly created repository that wishes to actively use kind/design will have to send in a PR to k/test-infra/label_sync  adding the respective repository's entry (if it did not already exist) followed by specifying an entry for the kind/design label.
When discussed on the original issue for this migration , the maintainers of the following repositories came forth saying that they actively use kind/design:
which is why you will see these three repositories as "opted-in" for kind/design use in the migration PR .
If any other repository also uses or would like to use kind/design please reply to this email saying so by 27th September 2021, post which kind/design will be deleted:
- kind/design on all issues and PRs of said repository will be deleted.
- kind/design will be deleted from the list of labels of the said repository.
Please note that it is being done this way to try and keep our source of intent  and our source of truth (the state of the labels on the repository), as identical as possible.
This will be the case for all repositories that did not opt-in via this email. Please note that you can still opt-in at a later point by sending in a PR to  as mentioned above.