[PR Template] Add codeblock to capture primary sig associated with PR #82449
Conversation
k8s-ci-robot
added
the
release-note-none
k8s-ci-robot
added
kind/documentation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: paulbouwer The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
sig/release
|
/retest |
| @@ -9,6 +9,21 @@ https://git.k8s.io/community/contributors/devel/sig-release/release.md#issuepr-k | |||
| 6. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests | |||
| --> | |||
|
|
|||
| **Which is the sponsoring or primary SIG associated with this PR?** | |||
There was a problem hiding this comment.
How is a casual/new contributor going to know what this means?
We have automation that adds sig labels at least some of the time - is there something we can do to use that, rather than put the onus on the contributor?
It just feels...hard to front-load all this when all I want to do is submit a wee little patch. I get it makes relnotes better but it makes it even less friendly towards contributors, and it's already fiendlishly difficult to doo all the incantations (and thus, folks often prefer to take their improvements elsewhere and the project misses out).
Perhaps instead of frontloading the PR template, we could have a checklist for this that a bot comments on later? :/ I know this is a hard problem.
There was a problem hiding this comment.
Currently, the labels added by the bot do not support us very much in terms of the release notes. They add more noise to the actual change than we might need, since we're targeting to have a format like this.
I'm not sure if we can solve the problem with automation (which is somehow linked to the release notes) without the need of user interaction.
| Label the sponsoring or primary SIG associated with this PR. | ||
|
|
||
| For reference on available SIGs, you can find more details at: | ||
| https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs |
There was a problem hiding this comment.
This link doesn't really tell you what to do; it's a list of labels. It doesn't say how to add a label to a PR (the bot commands are subtly different from the list of labels).
I'm actually confused if this wants me to label the SIG, or write a SIG name in the block, or both? And since formatting matters in both cases, we'd want an example for each.
| @@ -9,6 +9,21 @@ https://git.k8s.io/community/contributors/devel/sig-release/release.md#issuepr-k | |||
| 6. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests | |||
| --> | |||
|
|
|||
| **Which is the sponsoring or primary SIG associated with this PR?** | |||
There was a problem hiding this comment.
Currently, the labels added by the bot do not support us very much in terms of the release notes. They add more noise to the actual change than we might need, since we're targeting to have a format like this.
I'm not sure if we can solve the problem with automation (which is somehow linked to the release notes) without the need of user interaction.
| For reference on available SIGs, you can find more details at: | ||
| https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs | ||
|
|
||
| Add only ONE sig here, by adding the sig name in the primary-sig block below. |
There was a problem hiding this comment.
How about adding a note like:
If you are not sure about which SIG is the primary one, then simply leave the field blank.
|
@paulbouwer are you still around to work on this or should I take it over? |
|
@saschagrunert - happy to still collaborate on this. |
Cool 👍, @justaugustus can we agree on an implementation before we move forward? |
|
This PR might be irrelevant if we do something like this: kubernetes/release#923 |
|
This needs to stay open until we have a community decision on kind vs SIG. I'll send a note out next week since US folks are on holiday now. |
k8s-ci-robot
added
the
area/release-eng
|
After getting community feedback, we merged using kind instead of SIG in kubernetes/release#923, so this is no longer being considered. /close |
|
@justaugustus: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Adds a code block to the PR Template for the kubernetes/kubernetes repo to capture the primary sig information as requested in Issue kubernetes/sig-release#668
Which issue(s) this PR fixes:
Refers to Issue kubernetes/sig-release#668
Special notes for your reviewer:
This is a smaller focused PR that was extracted from PR kubernetes/kubernetes #81278
This will require an update to the release notes tool for the next release cycle (1.17) to ensure that the primary sig information is parsed and processed.
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/cc @saschagrunert @onyiny-ang
/sig release