summaryrefslogtreecommitdiff
path: root/contributors/guide/issue-triage.md
diff options
context:
space:
mode:
Diffstat (limited to 'contributors/guide/issue-triage.md')
-rw-r--r--contributors/guide/issue-triage.md41
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.