This moves the issue triage guide into the contributor guide

2 files changed, 207 insertions, 206 deletions

diff --git a/contributors/devel/issues.md b/contributors/devel/issues.md
index 575eddff..ae6a36b4 100644
--- a/contributors/devel/issues.md
+++ b/contributors/devel/issues.md
@@ -1,206 +1 @@
-# Kubernetes Issue Triage Guidelines
-
-## Purpose
-
-Speed up issue management.
-
-The Kubernetes issues are listed at https://github.com/kubernetes/kubernetes/issues
-and are identified with labels. For example, an issue that belongs to SIG
-Network group will eventually be set to label `sig/network`. New issues will
-start out without any labels. The detailed list of labels can be found at
-https://github.com/kubernetes/kubernetes/labels. While working on triaging
-issues you may not have privilege to assign specific label (e.g. `triaged`)
-and in that case simply add a comment in the issue with your findings.
-
-Following are few predetermined searches on issues for convenience:
-* [Longest untriaged issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) (sorted by age)
-* [Needs to be assigned to a SIG](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc)
-* [Newest incoming issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue)
-* [Busy untriaged issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc) (sorted by number of comments)
-* [Issues that need more attention](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc)
-
-## Scope
-
-These guidelines serves as a primary document for triaging incoming issues to
-Kubernetes. SIGs and projects are encouraged to either use these guidelines, or
-use this as a starting point if necessary. For example if your SIG has specific
-triaging needs, extend these guidelines.
-**Note:** These guidelines only applies to the kubernetes repository. Its usage
-for other github repositories related to Kubernetes is TBD.
-
-## Using the bot
-
-Most people can leave comments and open issues. They don't have the ability to
-set labels, change milestones and close other peoples issues. For that we use
-a bot to manage labelling and triaging. The bot has a set of
-[commands and permissions](https://git.k8s.io/test-infra/commands.md)
-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. 
-If you do not have such privilege, just comment your findings. Otherwise, first
-`/assign` issue to yourself and then `/close`.
-
-### Support Structures
-
-Support requests should be directed to the following:
-
-* [User documentation](https://kubernetes.io/docs/) and
-[troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/)
-
-* [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) and
-[ServerFault](http://serverfault.com/questions/tagged/kubernetes)
-
-* [Slack](https://kubernetes.slack.com) ([registration](http://slack.k8s.io))
-  * Check out the [Slack Archive](http://kubernetes.slackarchive.io/) first.
-
-* [Email/Groups](https://groups.google.com/forum/#!forum/kubernetes-users)
-
-### User support response example
-
-If you see support questions on kubernetes-dev@googlegroups.com or issues asking for 
-support try to redirect them to Stack Overflow. Example response:
-
-```code
-Please re-post your question to [Stack Overflow]
-(http://stackoverflow.com/questions/tagged/kubernetes).
-
-We are trying to consolidate the channels to which questions for help/support
-are posted so that we can improve our efficiency in responding to your requests,
-and to make it easier for you to find answers to frequently asked questions and
-how to address common use cases.
-
-We regularly see messages posted in multiple forums, with the full response
-thread only in one place or, worse, spread across multiple forums. Also, the
-large volume of support issues on github is making it difficult for us to use
-issues to identify real bugs.
-
-Members of the Kubernetes community use Stack Overflow to field support
-requests. Before posting a new question, please search Stack Overflow for answers 
-to similar questions, and also familiarize yourself with:
-
-  * [user documentation](http://kubernetes.io/docs/)
-  * [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/)
-
-Again, thanks for using Kubernetes.
-
-The Kubernetes Team
-```
-
-## Find the right SIG(s)
-Components are divided among [Special Interest Groups (SIGs)](/sig-list.md). Find a proper SIG for the ownership of the issue using the bot:
-
-* Typing `/sig network` in a comment should add the sig/network label, for
-example.
-* Multiword SIGs use dashes, for example `/sig cluster-lifecycle`.
-
-Keep in mind that these commands must be on its own line and at the front of the
-comment.
-
-## Validate if the issue is bug
-
-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.
-
-## Define priority
-
-We use GitHub issue labels for prioritization. The absence of a priority label
-means the bug has not been reviewed and prioritized yet.
-
-We try to apply these priority labels consistently across the entire project,
-but if you notice an issue that you believe to be incorrectly prioritized,
-please do let us know and we will evaluate your counter-proposal.
-
-- **priority/critical-urgent**: Must be actively worked on as someone's top
-priority right now. Stuff is burning. If it's not being actively worked on,
-someone is expected to drop what they're doing immediately to work on it. Team
-leaders are responsible for making sure that all the issues, labeled with this
-priority, in their area are being actively worked on. Examples include
-user-visible bugs in core features, broken builds or tests and critical
-security issues.
-
-- **priority/failing-test**: Automatically filed frequently failing test. Needs
-to be investigated.
-
-- **priority/important-soon**: Must be staffed and worked on either currently,
-or very soon, ideally in time for the next release.
-
-- **priority/important-longterm**: Important over the long term, but may not be
-currently staffed and/or may require multiple releases to complete.
-
-- **priority/backlog**: There appears to be general agreement that this would be
-good to have, but we may not have anyone available to work on it right now or in
-the immediate future. Community contributions would be most welcome in the mean
-time (although it might take a while to get them reviewed if reviewers are fully
-occupied with higher priority issues, for example immediately before a release).
-
-- **priority/awaiting-more-evidence**: Possibly useful, but not yet enough
-support to actually get it done. These are mostly place-holders for potentially
-good ideas, so that they don't get completely forgotten, and can be referenced
-/deduped every time they come up.
-
-## Set ownership
-
-If you are not sure of who should own issue, defer to the
-SIG label only. If you feel the issue should warrant a notification,you can ping
-a team with an @ mention, in this format, `@kubernetes/sig-<group-name>-<group-suffix>`.
-Here the `<group-suffix>` can be one of `bugs, feature-requests, pr-reviews, test-failures, proposals`.
-For example, `@kubernetes/sig-cluster-lifecycle-bugs, can you have a look at this?`
-
-If you think you can fix the issue and you are an issue reporter or a component
-organization member, assign it to yourself with just `/assign`. If you can not
-self-assign, leave a comment that you are willing to work on it and work on
-creating a PR.
-
-## Poke issue owner if PR is not created for it in 30 days
-
-If you see any issue which is owned by a developer but a PR is not created in 30
-days, a Triage engineer should contact the issue owner and ask for PR or release
-ownership as needed.
-
-## Poke SIG if a SIG label is assigned but no comment was added by SIG in 30 days
-
-Ideally the SIG lead should have a SIG member that is a first point
-of contact for SIG new issues. If an issue has a SIG label assigned and no
-action is taken by SIG in 30 days (e.g. no comment was added by SIG or no
-discussion was initiated) then gently poke SIG about this pending issue.
-Also consider attending one of the SIG meetings and brig up issue, if you feel
-this is appropriate.
-
-## Milestones
-
-We additionally use milestones, based on minor version, for determining if a bug
-should be fixed for the next release. These milestones will be especially
-scrutinized as we get to the weeks just before a release. We can release a new
-version of Kubernetes once they are empty. We will have two milestones per minor
-release.
-
-- **vX.Y**: The list of bugs that will be merged for that milestone once ready.
-
-- **vX.Y-candidate**: The list of bug that we might merge for that milestone. A
-bug shouldn't be in this milestone for more than a day or two towards the end of
-a milestone. It should be triaged either into vX.Y, or moved out of the release
-milestones.
-
-The above [priority](#define-priority) scheme still applies. The `priority/critical-urgent`
-and `priority/failing-test` issues are work we feel must get done before
-release.  The `priority/important-soon` and `priority/important-longterm`
-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.
++**NOTE:** This document has moved to [a new location](/community/contributors/guide/issue-triage.md)
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md
new file mode 100644
index 00000000..581c386c
--- /dev/null
+++ b/contributors/guide/issue-triage.md
@@ -0,0 +1,206 @@
+# Kubernetes Issue Triage Guidelines
+
+## Purpose
+
+Speed up issue management.
+
+The Kubernetes issues are listed at https://github.com/kubernetes/kubernetes/issues
+and are identified with labels. For example, an issue that belongs to SIG
+Network group will eventually be set to label `sig/network`. New issues will
+start out without any labels. The detailed list of labels can be found at
+https://github.com/kubernetes/kubernetes/labels. While working on triaging
+issues you may not have privilege to assign specific label (e.g. `triaged`)
+and in that case simply add a comment in the issue with your findings.
+
+Following are few predetermined searches on issues for convenience:
+* [Longest untriaged issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) (sorted by age)
+* [Needs to be assigned to a SIG](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc)
+* [Newest incoming issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue)
+* [Busy untriaged issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc) (sorted by number of comments)
+* [Issues that need more attention](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc)
+
+## Scope
+
+These guidelines serves as a primary document for triaging incoming issues to
+Kubernetes. SIGs and projects are encouraged to either use these guidelines, or
+use this as a starting point if necessary. For example if your SIG has specific
+triaging needs, extend these guidelines.
+**Note:** These guidelines only applies to the kubernetes repository. Its usage
+for other github repositories related to Kubernetes is TBD.
+
+## Using the bot
+
+Most people can leave comments and open issues. They don't have the ability to
+set labels, change milestones and close other peoples issues. For that we use
+a bot to manage labelling and triaging. The bot has a set of
+[commands and permissions](https://git.k8s.io/test-infra/commands.md)
+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. 
+If you do not have such privilege, just comment your findings. Otherwise, first
+`/assign` issue to yourself and then `/close`.
+
+### Support Structures
+
+Support requests should be directed to the following:
+
+* [User documentation](https://kubernetes.io/docs/) and
+[troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/)
+
+* [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) and
+[ServerFault](http://serverfault.com/questions/tagged/kubernetes)
+
+* [Slack](https://kubernetes.slack.com) ([registration](http://slack.k8s.io))
+  * Check out the [Slack Archive](http://kubernetes.slackarchive.io/) first.
+
+* [Email/Groups](https://groups.google.com/forum/#!forum/kubernetes-users)
+
+### User support response example
+
+If you see support questions on kubernetes-dev@googlegroups.com or issues asking for 
+support try to redirect them to Stack Overflow. Example response:
+
+```code
+Please re-post your question to [Stack Overflow]
+(http://stackoverflow.com/questions/tagged/kubernetes).
+
+We are trying to consolidate the channels to which questions for help/support
+are posted so that we can improve our efficiency in responding to your requests,
+and to make it easier for you to find answers to frequently asked questions and
+how to address common use cases.
+
+We regularly see messages posted in multiple forums, with the full response
+thread only in one place or, worse, spread across multiple forums. Also, the
+large volume of support issues on github is making it difficult for us to use
+issues to identify real bugs.
+
+Members of the Kubernetes community use Stack Overflow to field support
+requests. Before posting a new question, please search Stack Overflow for answers 
+to similar questions, and also familiarize yourself with:
+
+  * [user documentation](http://kubernetes.io/docs/)
+  * [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/)
+
+Again, thanks for using Kubernetes.
+
+The Kubernetes Team
+```
+
+## Find the right SIG(s)
+Components are divided among [Special Interest Groups (SIGs)](/sig-list.md). Find a proper SIG for the ownership of the issue using the bot:
+
+* Typing `/sig network` in a comment should add the sig/network label, for
+example.
+* Multiword SIGs use dashes, for example `/sig cluster-lifecycle`.
+
+Keep in mind that these commands must be on its own line and at the front of the
+comment.
+
+## Validate if the issue is bug
+
+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.
+
+## Define priority
+
+We use GitHub issue labels for prioritization. The absence of a priority label
+means the bug has not been reviewed and prioritized yet.
+
+We try to apply these priority labels consistently across the entire project,
+but if you notice an issue that you believe to be incorrectly prioritized,
+please do let us know and we will evaluate your counter-proposal.
+
+- **priority/critical-urgent**: Must be actively worked on as someone's top
+priority right now. Stuff is burning. If it's not being actively worked on,
+someone is expected to drop what they're doing immediately to work on it. Team
+leaders are responsible for making sure that all the issues, labeled with this
+priority, in their area are being actively worked on. Examples include
+user-visible bugs in core features, broken builds or tests and critical
+security issues.
+
+- **priority/failing-test**: Automatically filed frequently failing test. Needs
+to be investigated.
+
+- **priority/important-soon**: Must be staffed and worked on either currently,
+or very soon, ideally in time for the next release.
+
+- **priority/important-longterm**: Important over the long term, but may not be
+currently staffed and/or may require multiple releases to complete.
+
+- **priority/backlog**: There appears to be general agreement that this would be
+good to have, but we may not have anyone available to work on it right now or in
+the immediate future. Community contributions would be most welcome in the mean
+time (although it might take a while to get them reviewed if reviewers are fully
+occupied with higher priority issues, for example immediately before a release).
+
+- **priority/awaiting-more-evidence**: Possibly useful, but not yet enough
+support to actually get it done. These are mostly place-holders for potentially
+good ideas, so that they don't get completely forgotten, and can be referenced
+/deduped every time they come up.
+
+## Set ownership
+
+If you are not sure of who should own issue, defer to the
+SIG label only. If you feel the issue should warrant a notification,you can ping
+a team with an @ mention, in this format, `@kubernetes/sig-<group-name>-<group-suffix>`.
+Here the `<group-suffix>` can be one of `bugs, feature-requests, pr-reviews, test-failures, proposals`.
+For example, `@kubernetes/sig-cluster-lifecycle-bugs, can you have a look at this?`
+
+If you think you can fix the issue and you are an issue reporter or a component
+organization member, assign it to yourself with just `/assign`. If you can not
+self-assign, leave a comment that you are willing to work on it and work on
+creating a PR.
+
+## Poke issue owner if PR is not created for it in 30 days
+
+If you see any issue which is owned by a developer but a PR is not created in 30
+days, a Triage engineer should contact the issue owner and ask for PR or release
+ownership as needed.
+
+## Poke SIG if a SIG label is assigned but no comment was added by SIG in 30 days
+
+Ideally the SIG lead should have a SIG member that is a first point
+of contact for SIG new issues. If an issue has a SIG label assigned and no
+action is taken by SIG in 30 days (e.g. no comment was added by SIG or no
+discussion was initiated) then gently poke SIG about this pending issue.
+Also consider attending one of the SIG meetings and brig up issue, if you feel
+this is appropriate.
+
+## Milestones
+
+We additionally use milestones, based on minor version, for determining if a bug
+should be fixed for the next release. These milestones will be especially
+scrutinized as we get to the weeks just before a release. We can release a new
+version of Kubernetes once they are empty. We will have two milestones per minor
+release.
+
+- **vX.Y**: The list of bugs that will be merged for that milestone once ready.
+
+- **vX.Y-candidate**: The list of bug that we might merge for that milestone. A
+bug shouldn't be in this milestone for more than a day or two towards the end of
+a milestone. It should be triaged either into vX.Y, or moved out of the release
+milestones.
+
+The above [priority](#define-priority) scheme still applies. The `priority/critical-urgent`
+and `priority/failing-test` issues are work we feel must get done before
+release.  The `priority/important-soon` and `priority/important-longterm`
+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.