diff options
Diffstat (limited to 'contributors')
| -rw-r--r-- | contributors/guide/issue-triage.md | 41 |
1 files changed, 29 insertions, 12 deletions
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md index 140762f8..08f0c3f5 100644 --- a/contributors/guide/issue-triage.md +++ b/contributors/guide/issue-triage.md @@ -39,10 +39,10 @@ and this document will cover the basic ones. ## Determine if it's a support request Sometimes users ask for support requests in issues; these are usually requests -from people who need help configuring some aspect of Kubernetes. These should be -directed to our support structures (see below) and then closed. Also, if the issue -is clearly abandoned or in the wrong place, it should be closed. Keep in mind that -only issue reporter, assignees and component organization members can close issue. +from people who need help configuring some aspect of Kubernetes. These issues should be +labeled with `kind/support`, directed to our support structures (see below) and then closed. Also, if the issue +is clearly abandoned or in the wrong place, it should be closed. Keep in mind that +only issue reporter, assignees and component organization members can close issue. If you do not have such privilege, just comment your findings. Otherwise, first `/assign` issue to yourself and then `/close`. @@ -108,14 +108,16 @@ Validate if the problem is a bug by reproducing it. If reproducible, move to the next step of defining priority. You may need to contact the issue reporter in the following cases: * Do a quick duplicate search to see if the issue has been reported already. If -a duplicate is found, let the issue reporter know it by marking it duplicate. -* If you can not reproduce the issue, contact the issue reporter with your -findings and close the issue if both the parties agree that it could not be -reproduced. -* If the issue is non-trivial to reproduce, work with issue reporter and let SIG -know of your findings. -* If you do not get a response in 20 days, then close the issue with appropriate -comment. +a duplicate is found, let the issue reporter know it by marking it duplicate. Label +such issues as `triage/duplicate`. +* If you can not reproduce the issue, label it as a `triage/not-reproducible`. +Contact the issue reporter with your findings and close the issue if both the parties +agree that it could not be reproduced. +* If you need more information to further work on the issue, let the reporter know it +by adding an issue comment followed by label `triage/needs-information`. + +In all cases, if you do not get a response in 20 days then close the issue with +an appropriate comment. ## Define priority @@ -204,3 +206,18 @@ issues are work we would merge into the release if it gets done, but we wouldn't block the release on it. A few days before release, we will probably move all `priority/important-soon` and `priority/important-longterm` bugs out of that milestone in bulk. + +## Closing issues +Issues that are identified as a support request, duplicate, not-reproducible or +lacks enough information from reporter should be closed following guidelines explained +in this file. Also, any issues that can not be resolved because of any particular reason +should be closed. These issues should have one or more of following self-readable +labels: +* `kind/support` +* `triage/duplicate` +* `triage/not-reproducible` +* `triage/needs-information` +* `triage/unresolved` + +A triage engineer should add these labels appropriately. Kubernetees GitHub Org members can +search issues per these labels to find ones that can be quickly closed. |