1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
# SIG Node Triage Process
Currently, SIG Node is limiting its triage review to pull requests. In the
near-future, we hope to expand to issues as well.
This is intended to guide developers through the SIG Node triage process. You
will learn about the roles of authors, reviewers, and approvers, as well as
what labels are required for each stage of the PR process.
We track most node PRs on the [SIG Node Triage project board]. All test and
CI-related PRs are tracked on the [CI subproject board].
For help with the commands listed in the document below, review the [bot command documentation].
[SIG Node Triage project board]: https://github.com/orgs/kubernetes/projects/49
[CI subproject board]: https://github.com/orgs/kubernetes/projects/43
[bot command documentation]: https://go.k8s.io/bot-commands
## Triage
All new PRs added to the board should begin in the **Triage** column.
When a pull request is made against kubernetes/kubernetes, it will typically
have the following [labels], applied by the Prow bot:
- needs-ok-to-test (not needed for project members)
- needs-kind
- needs-priority
- needs-triage
In order to be moved out of this column, all of the above labels must be set.
[labels]: https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md
### needs-ok-to-test
Use your best judgment in determining whether a PR is OK to test. You don't
have to do a full review: just make sure that the code does not appear to be
actively malicious, and the PR appears to be doing something useful. Use the
command `/ok-to-test`.
Only [Kubernetes org members] can add this [label][labels].
If the PR is trivial and doesn't provide much value, feel free to close it
using the `/close` command and link the author to the [trivial edits policy].
You can use the following message:
/close
Thank you for your PR. It seems to only contain trivial edits. Please read our [trivial edits policy](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#trivial-edits). We encourage you to take a look at confirmed issues and bugs or issues marked `help-wanted`.
[Kubernetes org members]: https://github.com/kubernetes/community/blob/master/community-membership.md#member
[trivial edits policy]: https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#trivial-edits
### needs-kind
Most authors will already set this, as it's part of the PR template, but they
may not set it correctly. A PR may have multiple "kind" labels, so ensure only
the correct ones are applied.
Anyone can add these [labels].
- **kind/api-change:** API change, that will require special API review
- **kind/bug:** related to a bug
- **kind/cleanup:** cleaning up code, process, or technical debt
- **kind/deprecation:** deprecation, that will require special API review
- **kind/documentation:** related to documentation (including code comments)
- **kind/failing-test:** related to a consistently or frequently failing test
- **kind/feature:** related to a new feature or enhancement; should have an
associated KEP linked
- **kind/flake:** related to a flaky test
- **kind/regression:** related to a regression in performance or functionality
from a prior release
- **kind/support:** not applicable to PRs
### needs-priority
You can take a quick look at what the PR is addressing and then apply a
priority label.
Anyone can add this [label][labels].
- **priority/critical-urgent:** Urgent bug fix, required ASAP. If not
addressed, will block a release. These issues should always be discussed in
the `#sig-node` channel on Slack.
- **priority/important-soon:** Needs to be completed this release. Important
bug fixes + KEPs targeted for the current milestone.
- **priority/important-longterm:** Has an attached issue/KEP, but unclear what
the specific priority is.
- **priority/backlog:** Non-urgent changes such as minor performance
optimizations, improving error logs, increasing test code coverage, code
refactoring, and addressing static code analysis issues.
### needs-triage
There are two more things to check before accepting a PR for triage.
The first is whether the SIG is correct. If the PR does not appear to touch SIG
Node code or require a SIG Node approver, you should remove the SIG Node label,
and add other SIG labels as appropriate.
The second is verifying the kind of PR. Most will be bug fixes, cleanups, or
documentation. Feature PRs should generally have an attached KEP. API changes
and deprecations require special review; those labels may be mistakenly
applied, so check over the PR to make sure they're accurate.
Once you've quickly looked over a PR, applied the appropriate labels, and it
looks ready to proceed to review (i.e. it doesn't have any labels that would
mean it's waiting on more work from the author), you can mark the PR as triaged
with `/triage accepted`.
Only [Kubernetes org members] can add this [label][labels].
## Waiting on Author
This column means that the PR is waiting on some action from the author. A
reviewer may have requested changes, or a PR may have one of the following
do-not-merge [labels]:
- **do-not-merge/hold:** usually set by a reviewer
- **do-not-merge/work-in-progress:** usually set by an author
- **do-not-merge/release-note-needed:** needs a release note to be added by the
author, [Kubernetes org members] can override with `/release-note-none` if
not required
- **do-not-merge/contains-merge-commits:** PR needs to be rebased
- **needs-rebase:** PR needs to be rebased
If [tests are failing] due to an issue with the change (rather than a [flake]), PRs
should also be assigned to this column.
Authors are encouraged to fix any of the label issues above, resolve or reply
to all PR feedback, and leave a comment indicating when their PR is ready for
review.
PRs that do not have any of the above labeled in this column should be
evaluated occasionally to see if they are ready for review.
If PRs are not updated for a long period (90d), they will be marked as stale.
After 30d more, they will be marked as rotten, and then closed automatically.
Reviewers should feel free to close stale PRs (4+ months of no changes) with a
note that the author can reopen when they are ready to work on it.
[tests are failing]: /contributors/devel/sig-testing/testing.md#troubleshooting-a-failure
[flake]: /contributors/devel/sig-testing/flaky-tests.md
## Waiting on Reviewer
This PR needs review! If you're not sure how to review a PR, start by
familiarizing yourself with the Kubernetes [pull request guidelines] and
[review guidelines].
PRs in this column must have the following [labels] set:
- triage-accepted
- priority
- kind
Only [Kubernetes org members] can add an `/lgtm`.
If you want to become an official Node reviewer, you should read through the
[reviewer responsibilities and requirements].
As part of code review, you should ensure that:
- the change is needed
- the metadata on the PR and the release note are accurate
- the change works the way it is intended to
- alternative implementations have been explored and this is an appropriate
solution
- the code has been reviewed by everyone it needs to be: it may have an LGTM
label already, but still needs feedback from Node reviewers
TODO: Add some node-specific stuff here.
[pull request guidelines]: https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md
[review guidelines]: https://github.com/kubernetes/community/blob/master/contributors/guide/review-guidelines.md
[reviewer responsibilities and requirements]: https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer
## Waiting on Approver
These PRs are waiting on an `approved` label that can only be provided by
approvers. The bot will always tell you whose approval is needed on which
directories ([example comment]), and will update its comment as approvals are
provided.
PRs in this column must have the following [labels] set:
- lgtm
- triage-accepted
- priority
- kind
Check for the bot's comment to see which files still need approvers from the
appropriate OWNERS. If the PR already has an approval for the node components
(commonly, anything in `./pkg/kubelet/*`), you can mark the PR as Done manually
while waiting on other approvers.
Only [Kubernetes approvers] can use `/approve` on a PR to address this
requirement.
[example comment]: https://github.com/kubernetes/kubernetes/pull/97992#issuecomment-759450299
[Kubernetes approvers]: https://github.com/kubernetes/community/blob/master/community-membership.md#approver
## Done
This column has automation to include all closed and merged PRs on the board.
Huzzah!
It may also include PRs that have LGTMs and approvals, but are not yet merged
(i.e. requires a non-node approver signoff, API review, or a release team
cherry-pick approval).
TODO: We should archive this column per release.
|
