Merge pull request #1694 from castrojo/move-issue-triage
Move issue triage guide into the contributor guide
This commit is contained in:
k8s-ci-robot
GitHub
commit
05ccea37f2
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -107,6 +107,7 @@ Follow the link in the SIG name column to reach each SIGs README. Most SIGs will
|
|||
### File an Issue
|
||||
|
||||
Not ready to contribute code, but see something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue (aka problem). Issues should be filed under the appropriate Kubernetes subrepository.
|
||||
Check the [issue triage guide](./issue-triage.md) for more information.
|
||||
|
||||
*Example:* a documentation issue should be opened to [kubernetes/website](https://github.com/kubernetes/website/issues).
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue