Change:
**Does this PR introduce a user-facing change?**: <!-- <del> If no, just write "NONE". </del> <ins> If no, just write "NONE" in the release-note block below. </ins> If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". -->

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: The PR template is a little unclear to new contributors. EG: If I understand what "uncomment" is, and leave it on it's own line I get: which has two problems: I probably left the space after the (so the bot regex won't match) I probably didn't put a newline before the uncommented line, which is necessary for it to not just continue to be a comment block: What type of PR is this? /kind cleanup vs What type of PR is this? /kind cleanup Another issue is in this bit: release-note release-note NONE If you're not an experienced contributor, it's not very clear where you should write "NONE" and what kind of quoting you should use, etc. What you expected to happen: I hope for the PR template to be a little more obvious and easy to use How to reproduce it (as minimally and precisely as possible): create a new PR Anything else we need to know?: /sig contributor-experience cc Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/remove-kind cleanup
/assign
GitHub didn't allow me to assign the following users: paralika. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would like to work on this issue.
was an improvement but many of the original observations still stand. Here's what I found looking at 75 latest PRs (~67 human-written ones if you discount 8 "Automated cherry pick"): The instruction to "uncomment only one /kind line" seems to suggest keeping all the other options present with prefix, but few people do that! I found just 7, of which: 2 PRs retained that whole section of the template, not picking a kind at all.

1 of these still got kind label magically set by the bot (possibly from linked issue?) I confirmed (tip: ⋯ -Quote reply lets you see the markdown source) these were NOT people that removed but forgot newline, getting bitten by markdown "lazy continuation" rule — they retained on all lines. 3 PRs uncommented 1 line. 2 PRs uncommented multiple lines, resulting in multile kind/... labels! Example: I don't know if you'll want to encourage "Uncomment one or more", or want to keep it a "hidden feature" for experienced users? However, from the (secondary) angle "template teaches people how the project/infrastructure works", the "only one" wording is slightly misleading — it obscures the fact /kind just sets a label, similar to /area, /sig etc. (and from what I saw, multiple areas or SIGs are common?) One hypothesis is people feel leaving the rest is noise that detracts from writing & reading the description? Weak evidence that's not the only motivation: a few (didn't count, I'd say ~3) retained the instructions line, which is clearly noise, e.g.: I don't think we can measure this, but see below. Found 3 of these, these are actual failures of the process! ~5% of people took the effort to choose a kind but didn't understand the "uncomment" instruction :cryingcatface: (bot assigned kind/cleanup anyway, not sure how)
It seems delete-all-irrelevant mechanic is better than "uncomment" mechanic. It avoids markdown pitfall, the end result has less noise, and most people choose it anyway. What if the template had them without prefixes? This would prevent mistakes of the last kind, where prevented bot from seeing contributor's choice! A downside is that when somebody is lazy / misses this step, they'll create PRs with ALL kind/ labels :worried: Is the bot smart about /commands inside fenced blocks? Or HTML comments? If yes, could use them as a signal that you made a conscious choice: I've also seen projects that use checklists in templates: downsides: Would require bot support to understand it.

It's slightly worse on the "template teaches people how the project/infrastructure works" angle — you won't learn from that these are regular /commands you can just write wherever. Misses on benefits of "delete" mechanic. People will likely delete anyway, with same mild confusion about two-ways-to-do-it. Well, this was too many words to suggest such small tweak :laughing:, but: exactly what to do, rather than vague "uncomment". Not sure if this will reduce mistakes of the last kind. space between avoids risk of leaving space mentioned in OP, without having to explain it. removing the rest =less worries, no markdown pitfall.
OK, that answers the question about bot & fenced blocks :grin: ^^^^^ /remove-kind api-change /remove-kind cleanup /remove-kind documentation /remove-kind failing-test /remove-kind feature
/remove-kind design /remove-kind flake