remove redundant fields from KEP issue template

[jenshu]

The KEP issue description often gets out of date, either due to people forgetting to update it or not having edit permissions. This can sometimes cause confusion for the release team since there may be conflicting info between the issue description and other issue fields / KEP files. Removed some of the redundant fields from the template:

• Primary contact: This often gets out of date with the current issue assignees. We can use the issue assignees as the source of truth.
• Responsible SIGs: We can get the relevant SIGs from the issue labels (e.g. sig/node etc), and the "primary" SIG can be found from the KEP file path (e.g. keps/<sig>/NNNN-kep-name/...)
• Enhancement target: We can get the current target stage by inspecting the issue comments, issue milestone and labels, and can get the history from the kep.yaml.

It would be good to eventually get rid of the per-stage list of PRs, but would need to think through a good workflow for ensuring all relevant PRs for the milestone get linked to the issue.

cc @kikisdeliveryservice

Related to #5124

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jenshu
Once this PR has been reviewed and has the lgtm label, please assign kikisdeliveryservice for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pohly]

It would be good to eventually get rid of the per-stage list of PRs, but would need to think through a good workflow for ensuring all relevant PRs for the milestone get linked to the issue.

The simplest solution would be to have all PRs reference the KEP issue with Related-to: https://github.com/kubernetes/enhancements/issues/<KEP-issue-number>. Then GitHub will automatically cross-reference the PR in the issue.

Instead, what people currently do is put some reference to the KEP (link to issue or link to README - we don't have good guidance for it) into the opaque "Additional documentation" section:
https://github.com/kubernetes/kubernetes/blob/2342c0912a947d0a1fc28918eb2f52f0146b42d5/.github/PULL_REQUEST_TEMPLATE.md?plain=1#L64-L71

If I could choose, I would drop that entire "Additional documentation" section. I don't think it is used consistently enough to be useful and creates additional work for those who haven't given up on it yet. If we want the KEP link, then it can be found also through the Related-to link.

[jenshu]

The simplest solution would be to have all PRs reference the KEP issue with Related-to: https://github.com/kubernetes/enhancements/issues/

@pohly Agreed, ideally all PRs would mention the KEP issue number in the PR description.

What do you think if we make a modification to the k/k PR template here that says you either use Fixes (if the PR should close the issue) or Related to (if the PR shouldn't close the issue) and that it should be filled in for KEP-related PRs?

[pohly]

I think I've seen "Related-to" more often than "Related to". That aside, I think we can tweak that template slightly without making it longer. I wouldn't mention KEPs specifically.

<!--
Automatically closes linked issue when PR is merged.
Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`.
If PR is about `failing-tests or flakes` or provides a partial solution, then please use `Related-to` instead of `Fixes`.
-->
Fixes #

I've removed the Markdown markup inside the comment block. It doesn't get rendered and "._*" at the end of the last line just looked odd.

[jenshu]

@pohly what do you think of the changes here: kubernetes/kubernetes#131944

I didn't explicitly mention "Related-to" since technically the words coming before the issue link can be anything besides the reserved words here https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword