make kind/docs a valid label

[aclevername]

Description

Proof we don't respect our docs 😂 , noticed in #3233 that providing the kind/docs label doesn't fix the failing pr-label action

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[michaelbeaumont]

We can change this but the reason for enforcing the labels was to make sure the release-drafter catches all the PRs it should catch (leaving aside the fact that it doesn't 100% work) or you have to explicitly pick skip-release-notes. Since we don't have a docs section in the notes, this means kind/docs are implicitly skipped.

[aclevername]

We can change this but the reason for enforcing the labels was to make sure the release-drafter catches all the PRs it should catch (leaving aside the fact that it doesn't 100% work) or you have to explicitly pick skip-release-notes. Since we don't have a docs section in the notes, this means kind/docs are implicitly skipped.

Ah I see, I think docs are important so having it be a valid label is good, but should it be in the release notes? I'm not sure, it is technically delivering value 🤷

[michaelbeaumont]

They should be left out of the notes in most cases I think, I just wanted to call attention to the fact that the check sort of serves a different purpose then.