Describe new labels in triage guidelines

Recently we have added new labels to identify issues that are candidates for close.
These issues are typically the one which are not goint to close via a fix. Add
description in triage guidelines about when to use these labels.
Related PR is,
https://github.com/kubernetes/test-infra/pull/7554

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.