diff options
| -rw-r--r-- | contributors/guide/issue-triage.md | 411 |
1 files changed, 211 insertions, 200 deletions
diff --git a/contributors/guide/issue-triage.md b/contributors/guide/issue-triage.md index 7dc0d0a6..c1a146db 100644 --- a/contributors/guide/issue-triage.md +++ b/contributors/guide/issue-triage.md @@ -4,57 +4,227 @@ weight: 10 slug: "issue-triage" --- -## Purpose +# Issue Triage: A Primer + +## Table of Contents +- [Scope](#scope) +- [What Is Triaging?](#what-is-triaging) +- [Why Is Triaging Beneficial?](#why-is-triaging-beneficial) +- [How to Triage: A Step-by-Step Flow](#how-to-triage-a-step-by-step-flow) + - [Triage-Related Tools](#triage-related-tools) + - [Permissions and the Bot](#permissions-and-the-bot) + - [Gubernator](#gubernator) + - [GitHub Project Boards](#github-project-boards) + - [DevStats](#devstats) + - [Process Pointers and Advice from SIGs](#process-pointers-and-advice-from-sigs) + - [Running a Triage Meeting: Tips from api-machinery](#running-a-triage-meeting-tips-from-api-machinery) + - [Triage Guide by cluster-lifecycle](#triage-guide-by-cluster-lifecycle) + - [Step One: Review Newly Created Open Issues](#step-one-review-newly-created-open-issues) + - [Conducting Searches](#conducting-searches) + - [Step Two: Triage Issues by Type](#step-two-triage-issues-by-type) + - [Support Requests](#support-requests) + - [Abandoned or Wrongly Placed Issues](#abandoned-or-wrongly-placed-issues) + - [Needs More Information](#needs-more-information) + - [Bugs](#bugs) + - [Help Wanted/Good First Issues](#help-wantedgood-first-issues) + - [Kind Labels](#kind-labels) + - [Step Three: Define Priority](#step-three-define-priority) + - [Step Four: Find and Set the Right SIG(s) to Own an Issue](#step-four-find-and-set-the-right-sigs-to-own-an-issue) + - [Self-Assigning](#self-assigning) + - [Step Five: Follow Up](#step-five-follow-up) + - [If No PR Is Created for an Issue Within the Current Release Cycle](#if-no-pr-is-created-for-an-issue-within-the-current-release-cycle) + - [If a SIG Label Is Assigned, but No Action Is Taken Within 30 Days](#if-a-sig-label-is-assigned-but-no-action-is-taken-within-30-days) + - [If an Issue Has No Activity After 90 Days](#if-an-issue-has-no-activity-after-90-days) + - [Footnotes](#footnotes) + - [Support Requests: Channels](#support-requests-channels) + - [User Support Response: Example](#user-support-response-example) + +## Scope +These guidelines serve as a primary document for triaging incoming issues to Kubernetes. SIGs and projects are encouraged to use this guidance as a starting point, and customize to address specific triaging needs. + +**Note:** These guidelines only apply to the Kubernetes repository. Usage for other Kubernetes-related GitHub repositories is TBD. + +## What Is Triaging? +Issue triage is a process by which a SIG intakes and reviews new GitHub issues and requests, and organizes them to be actioned—either by its own members, or by other SIGs. Triaging involves categorizing issues and pull requests based on factors such as priority/urgency, SIG ownership of the issue, and the issue kind (bug, feature, etc.) +- the SIG or SIGs responsible for handling the issue or pull request + +Triage can happen asynchronously and continuously, or in regularly scheduled meetings. Several Kubernetes SIGs and projects have adopted their own approaches to triaging. + +## Why Is Triaging Beneficial? +SIGs who triage regularly say it: +- speeds up issue management +- keeps contributors engaged by shortening response times +- prevents work from lingering endlessly +- replaces "special requests" and one-offs with a neutral process that acts like a boundary +- leads to greater transparency, interesting discussions, and more collaborative, informed decision-making +- it helps build prioritization, negotiation and decision-making skills, which are critical to most tech roles +- it reinforces SIG community and culture -Speed up issue management. +People who enjoy product management and iterating on processes tend to enjoy triaging because it empowers their SIGs to maintain a steady, continuous flow of work that is assessed and prioritized based on feedback and value. -The Kubernetes issues are listed at https://github.com/kubernetes/kubernetes/issues -and are identified with labels. For example, an issue that belongs to the 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 a specific label (e.g. `triaged`) -and in that case simply add a comment in the issue with your findings. +# How to Triage: A Step-by-Step Flow +This aims to walk you through a standard triaging process, first covering tools and tips. -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+label%3Aneeds-sig) -* [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) +## Triage-Related Tools +These tools that your SIG can use to make the process simpler, more efficient and faster. -## Scope +### Permissions and the Bot +Opening new issues and leaving comments on other people's issues are possible for all contributors. However, permission to assign specific labels (e.g. `triage`), change milestones, or close other contributors issues is only granted to the author of an issue, assignees, and organization members. For this reason, we use a bot to manage labelling and triaging. For a full list of commands and permissions, see the [Prow command reference page](https://go.k8s.io/bot-commands). + +### Gubernator +[Gubernator](https://gubernator.k8s.io/pr) offers a dashboard that tells you which pull requests are waiting for your feedback and which PRs are waiting for the contributor to respond. Please note that Gubernator only shows *pull requests*. You will not see which issues are assigned to you. + +### Triage Party +[Triage Party](https://github.com/google/triage-party) is a tool for triaging incoming GitHub issues for large open-source projects, built with the GitHub API. Made public in April 2020, it facilitates "massively multi-player GitHub triage" and reduces contributor response latency. + +Some of its features: +- Queries across multiple repositories +- Queries that are not possible on GitHub: + - conversation direction (`tag: recv`, `tag: send`) + - duration (`updated: +30d`) + - regexp (`label: priority/.*`) + - reactions (`reactions: >=5`) + - comment popularity (`comments-per-month: >0.9`) +- Multiplayer mode: for simultaneous group triage of a pool of issues +- Button to open issue groups as browser tabs (pop-ups must be disabled) +- "Shift-Reload" for live data pull + +### GitHub Project Boards +GitHub offers project boards, set up like kanban boards, to help teams organize and track their workflow in order to get work done. The Release Team has come to depend on [their project board](https://github.com/orgs/kubernetes/projects/29) for planning new Kubernetes releases; they also use it as an archive to show the work Done for past releases. Other SIGs using project boards: +- [Contributor Experience](https://github.com/orgs/kubernetes/projects/1) +- [Network](https://github.com/orgs/kubernetes/projects/10) +- [Windows](https://github.com/orgs/kubernetes/projects/8) + +We encourage more SIGs to use project boards to enhance visibility and tracking. If you'd like some help getting started, visit [GitHub's documentation](https://help.github.com/en/github/managing-your-work-on-github/about-project-boards) or reach out to [SIG Contributor Experience](/sig-contributor-experience/README.md#contact). + +### DevStats +The CNCF has created a [suite of Grafana dashboards and charts](https://devstats.cncf.io/) for collecting metrics related to all the CNCF projects. The [Kubernetes dashboard](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&refresh=15m) can be used to help SIGs view real-time metrics on many aspects of their workflow, including: +- [Issue Velocity](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&from=1587157094179&to=1587758294179&refresh=15m&panelId=8&fullscreen): How quickly issues are resolved +- [PR Velocity](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&from=1587157166022&to=1587758366022&refresh=15m&panelId=9&fullscreen): Including PR workload per SIG, PR time to approve and merge, and other data + +## Process Pointers and Advice from SIGs +Several SIGs consistently meet weekly or monthly to triage issues. Here are some details about their processes: + +### Running a Triage Meeting: Tips from api-machinery +The api-machinery SIG has found that triage meetings offer valuable opportunities for newcomers to listen, learn, and start contributing. api-machinery hold triage meetings every Tuesday and Thursday and archive recordings via their [Youtube playlist](https://www.youtube.com/playlist?list=PL69nYSiGNLP21oW3hbLyjjj4XhrwKxH2R); here is an [example](https://www.youtube.com/watch?v=bRptR9vd4S8&list=PL69nYSiGNLP21oW3hbLyjjj4XhrwKxH2R&index=2&t=13s). + +In a typical triage meeting, api-machinery members sort through every issue that they haven't triaged since the previous meeting, using a simple query and issue # to track Open PRs and Issues. They usually then: +- read through the comments and the code briefly to understand what the issue is about. +- determine by consensus if it belongs to the api-machinery SIG or not. If not, remove the `sig/api-machinery` label. +- label other SIGs, if appropriate +- discuss briefly the technical implications +- assign people with expertise in the domain to review, comment, reject, etc. + +api-machinery has found that consistently meeting on a regular, fixed schedule is key to the success of a triaging effort. More frequent, small meetings are better than infrequent, large meetings, they've found. A few other pointers: +- We try to balance the load, and ask people if they are okay taking on an issue before assigning it to them +- We skip issues that are closed +- We also skip cherrypicks, because we consider that the code change was reviewed in the original PR +- We ensure participation from the entire SIG and support company diversity. +- We use this opportunity to mark ["help needed", "good first issue"](#help-wantedgood-first-issues) + +### Triage Guide by cluster-lifecycle +The SIG has developed a [triaging page](/sig-cluster-lifecycle/grooming.md) detailing their process, including the [Milestones](#planning-milestones) stage. Here is a [March 2020 presentation](https://www.youtube.com/watch?v=Q07_PfkNjlw) delivered to the SIG chairs and leads group on their process. + +## Step One: Review Newly Created Open Issues +Kubernetes issues are listed [here](https://github.com/kubernetes/kubernetes/issues). New, untriaged issues come without labels attached. SIG leads should identify at least one SIG member to serve as a first point of contact for new issues. -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. +Labels are the primary tools for triaging. [Here's a comprehensive label list](https://github.com/kubernetes/kubernetes/labels). -## Using the bot +### Conducting Searches +GitHub allows you to filter out types of issues and pull requests, which helps you discover items in need of triaging. This table includes some predetermined searches for convenience: -Most people can leave comments and open issues. They don't have the ability to -set labels, change milestones and close other people's issues. For that we use -a bot to manage labelling and triaging. The bot has a set of -[commands and permissions](https://go.k8s.io/bot-commands) -and this document will cover the basic ones. +| Search | What it sorts | +|---|---| +| [created-asc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) | Untriaged issues by age | +| [needs-sig](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3Aneeds-sig) | Issues that need to be assigned to a SIG | +| [`is:open is:issue`](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue) | Newest incoming issues | +| [comments-desc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc) | Busiest untriaged issues, sorted by # of comments | +| [comments-asc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc) | Issues that need more attention, based on # of comments | -## Determine if it's a support request +We suggest preparing your triage by filtering out the oldest, unlabelled issues and/or pull requests first. -Sometimes users ask for support requests in issues; these are usually requests -from people who need help configuring some aspect of Kubernetes. These issues -should be labeled with `triage/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 reporters, -assignees and component organization members can close issues. If you do not -have such privilege, just comment your findings. Otherwise, first `/assign` -issue to yourself and then `/close`. +## Step Two: Triage Issues by Type +Use [these labels](https://github.com/kubernetes/kubernetes/labels?utf8=%E2%9C%93&q=triage%2F+kind%2Fsupport) to find open issues that can be quickly closed. A triage engineer can add the appropriate labels. + +Depending on your permissions, either close or comment on any issues that are identified as support requests, duplicates, or not-reproducible bugs, or that lack enough information from the reporter. + +### Support Requests +Some people mistakenly use GitHub issues to file support requests. Usually they're asking for help configuring some aspect of Kubernetes. To handle such an issue, direct the author to use our [support request channels](#support-requests-channels). Then apply the `triage/support` label, which is directed to our support structures, and apply the `close` label. + +Please find more detailed information about Support Requests in the [Footnotes section](#footnotes). + +### Abandoned or Wrongly Placed Issues +Either close or comment on it. -### Support Structures +### Needs More Information +* The `triage/needs-information` label indicates an issue needs more information in order to work on it; comment on or close it. -Support requests should be directed to the following: +### Bugs +First, validate if the problem is a bug by trying to reproduce it. +If you can reproduce it: +* [Define its priority](##step-three-define-priority) +* Do a quick duplicate search to see if the issue has been reported already. If a duplicate is found, let the issue reporter know, reference the original issue, and close the duplicate. + +If you can't reproduce it: +* Contact the issue reporter with your findings +* 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 `lifecycle/needs-information`. + +In all cases, if you do not get a response in 20 days then close the issue with an appropriate comment. If you have permission to close someone else's issue, first `/assign` the issue to yourself, then `/close` it. If you do not, please leave a comment describing your findings. + +### Help Wanted/Good First Issues +To identify issues that are specifically groomed for new contributors, we use the [help wanted](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) +and [good first issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) labels. To use these labels: +* Review our specific [guidelines](/contributors/guide/help-wanted.md) for how to use them. +* If the issue satisfies these guidelines, you can add the `help wanted` label with the `/help` command +and the `good first issue` label with the `/good-first-issue` command. Please note that adding the `good first issue` label will also automatically add the `help wanted` label. +* If an issue has these labels but does not satisfy the guidelines, please ask for more details to be added to the issue or remove the labels using the `/remove-help` or `/remove-good-first-issue` commands. + +### Kind Labels +Usually the `kind` label is applied by the person submitting the issue. Issues that feature the wrong `kind` (for example, support requests labelled as bugs) can be corrected by someone triaging; double-checking is a good approach. Our [issue templates](https://github.com/kubernetes/kubernetes/issues/new/choose) aim to steer people to the right kind. + +## Step Three: Define Priority +We use GitHub labels for prioritization. If an issue lacks a `priority` label, this means it has not been reviewed and prioritized yet. + +We aim for consistency across the entire project. However, if you notice an issue that you believe to be incorrectly prioritized, please leave a comment offering your counter-proposal and we will evaluate it. + +|Priority label|What it means|Examples| +|---|---|---| +| **priority/critical-urgent** | Team leaders are responsible for making sure that these issues (in their area) are being actively worked on—i.e., drop what you're doing. Stuff is burning. These should be fixed before the next release. | user-visible bugs in core features <br> broken builds <br> tests and critical security issues | +| **priority/important-soon** | Must be staffed and worked on either currently or very soon—ideally in time for the next release. Important, but wouldn't block a release. | [**XXXX**] | +| **priority/important-longterm** | Important over the long term, but may not be currently staffed and/or may require multiple releases to complete. Wouldn't block a release. | [**XXXX**]| +| **priority/backlog** | General agreement that this is a nice-to-have, but no one's available to work on it anytime soon. Community contributions would be most welcome in the meantime, though it might take a while to get them reviewed if reviewers are fully occupied with higher-priority issues—for example, immediately before a release.| [**XXXX**] | +| **priority/awaiting-more-evidence** | Possibly useful, but not yet enough support to actually get it done. | Mostly placeholders for potentially good ideas, so that they don't get completely forgotten, and can be referenced or deduped every time they come up | + +## Step Four: Find and Set the Right SIG(s) to Own an Issue +Components are divided among [Special Interest Groups (SIGs)](/sig-list.md). [The bot](https://go.k8s.io/bot-commands) assists in finding a proper SIG to own an issue. + +* For example, typing `/sig network` in a comment should add the sig/network label. +* Multiword SIGs use dashes: for example, `/sig cluster-lifecycle`. +* Keep in mind that these commands must be on their own lines, and at the front of the comment. +* If you are not sure about who should own an issue, defer to the SIG label only. +* If you feel an issue should warrant a notification, 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?` + +### Self-Assigning +If you think you can fix the issue, assign it to yourself with *just* the `/assign` label. If you cannot self-assign for permissions-related reasons, leave a comment that you'd like to claim it and work on creating a PR. + +## Step Five: Follow Up +### If no PR is created for an Issue Within the Current Release Cycle +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 them to either create a PR or release ownership. + +### If a SIG label Is Assigned, but No Action Is Taken Within 30 Days +If you find an issue with a SIG label assigned, but there's no evidence of movement or discussion within 30 days, then gently poke the SIG about this pending issue. Also, consider attending one of their meetings to bring up the issue, if you feel this is appropriate. + +### If an Issue Has No Activity After 90 Days +When this happens, the `fejta-bot` adds the `lifecycle/stale` label to that issue. You can block the bot by applying the `/lifecycle frozen` label preemptively, or remove the label with the `/remove-lifecycle stale` command. The `fejta-bot` adds comments in the issue that include additional details. If you take neither step, the issue will eventually be auto-closed. + +## Footnotes +### Support Requests: Channels +These should be directed to the following: * [User documentation](https://kubernetes.io/docs/home/) and [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/) @@ -65,10 +235,10 @@ Support requests should be directed to the following: * [Discussion forums](https://discuss.kubernetes.io) -### User support response example +### 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: +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) @@ -95,162 +265,3 @@ 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 their own lines, and at the front of the -comment. - -## Validate if the issue is a 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. 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 - -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/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 meantime -(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 an 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 cannot -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 bringing up the 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 bugs 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` 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. - -More information can be found in the developer guide section for -[targeting issues and PRs to a milestone release](/contributors/devel/sig-release/release.md). - -## 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: -* `triage/support`: Indicates an issues is not a bug but a support request. -* `triage/duplicate`: Indicates an issue is a duplicate of other open issue. -* `triage/not-reproducible`: Indicates an issue can not be reproduced as -described. -* `triage/needs-information`: Indicates an issue needs more information in -order to work on it. -* `triage/unresolved`: Indicates an issue that can not be resolved. - -A triage engineer should add these labels appropriately. Kubernetes GitHub -Org members can search [open issues per these labels](https://github.com/kubernetes/kubernetes/labels?utf8=%E2%9C%93&q=triage%2F+kind%2Fsupport+is%3Aopen) to find ones that can be -quickly closed. - -Also note that, `fejta-bot` will add `lifecycle/stale` label to issues with no -activity for 90 days. Such issues will be eventually auto closed if the label is -not removed with the `/remove-lifecycle stale` label or prevented with the -`/lifecycle frozen` label. Refer to the `fejta-bot` added comments in the issue -for more details. It is fine to add any of the `triage/*` labels described in -this issue triage guidelines to issues triaged by the `fejta-bot` for a better -understanding of the issue and closing of it. - -## Help Wanted issues - -We use two labels [help wanted](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) -and [good first issue](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) -to identify issues that have been specially groomed for new contributors. - -We have specific [guidelines](/contributors/guide/help-wanted.md) -for how to use these labels. If you see an issue that satisfies these -guidelines, you can add the `help wanted` label with the `/help` command -and the `good first issue` label with the `/good-first-issue` command. -Please note that adding the `good first issue` label will also automatically -add the `help wanted` label. - -If an issue has these labels but does not satisfy the guidelines, please -ask for more details to be added to the issue or remove the labels using -`/remove-help` or `/remove-good-first-issue` commands. |