# SIG Node bug scrub

This document outlines the goals and processes of SIG node bug triage.

As of 6/11/2021 we have [458 issues in sig/node](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+label%3Asig%2Fnode).

- **Date:** Jun 24th-25th globally, starting Thu. June 24 at 00:00 UTC until 23:99 on Fri. June 25
- **Regions:**
- Kickoff: 00:00 UTC June 24
- APAC: 01:00-09:00 UTC both days
- EMEA: 09:00-17:00 UTC both days
- NASA: 17:00-01:00 UTC both days, ending at 23:59 June 25
- **Mentor sign up sheet:** https://docs.google.com/spreadsheets/d/1y6HKIsThphzpaG2a-Vgsc66b36ckM_TIPqGJ6GeVUGI/edit#gid=0
- **Slack room:** [#sig-node-bug-scrub]
- **Zoom room:** [SIG Node Zoom](https://zoom.us/j/98127126159?pwd=am1oTEtnRXZ2bnpSTmorQlFTOWJYZz09)
- **Triage Party:** [Overall View](https://release.triage.k8s.io/s/sig-node-bsp?player=0&players=12)
- APAC: [Players 1](https://release.triage.k8s.io/s/sig-node-bsp?player=1&players=12) to 4
- EMEA: [Players 5](https://release.triage.k8s.io/s/sig-node-bsp?player=5&players=12) to 8
- NASA: [Players 9](https://release.triage.k8s.io/s/sig-node-bsp?player=9&players=12) to 12

[#sig-node-bug-scrub]: https://kubernetes.slack.com/archives/C02491CNJKZ

## Goals

Categorize, clean up, and resolve SIG Node issues.

## Code of Conduct

This event is governed by the [Kubernetes Code of Conduct](https://kubernetes.io/community/code-of-conduct/), and we want to make sure everyone can safely participate and have fun. If you need immediate help, please reach out to your region captain who will be clearly marked in the [#sig-node-bug-scrub] Slack channel topic, or follow the instructions to submit a report to the [Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct#reporting-an-incident).

## Get Help!

Region captains and mentors will be monitoring the [#sig-node-bug-scrub] Slack channel for any questions. The current region captains will be listed in the channel topic.

Start by reading through this doc. Once you're familiar with what you will be doing, ask a region captain or mentor to assign you bugs to work on. This will be provided with a link to Triage Party.

## Process

Triage party will be set up in "12 player" mode, which will give each of the 3 regions 4 bug views for us to divide and conquer them.

Each player view should have an assigned mentor. Over the next couple days, each mentor can coordinate work scrubbing bugs under their player view.

For example, APAC will be assigned players 1-4. Region captains will assign one mentor from the region to each view. That mentor will be responsible for working through those bugs and assigning bugs for attendees to look at.

## I'm brand new to Kubernetes, what should I do?

**Start here.**

At some point, that was all of us!

This is a great opportunity to get involved if you've never contributed to Kubernetes. We'll have dedicated mentors available to coordinate and help out new contributors.

If you've never contributed to Kubernetes before, I recommend you check out the [Getting Started](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [Contributor Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/README.md) resources in advance of the event. You will want to ensure you've signed the [contributor license agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).

Remember, you **don't have to code** to make valuable contributions! Triaging the bug tracker is a great example of this.

## What to do

At a high level, when scrubbing a bug, you will go through the following steps:

1. Review the issue
2. Confirm if the bug is correctly labeled
3. Reproduce the problem
4. (optional) Fix the problem!

### Review the issue

#### Ensure "kind" label is set correctly

- If it is a request for help, it should have **kind/support** set. Follow the instructions for [support requests](#Support-Requests).
- If it is a feature request, it should have **kind/feature** set. These will be reviewed after the bug scrub, so once the kind label is correctly set, you can move on to the next issue.
- *Optionally,* if you think it's important, you can add it to the [Node Feature Backlog](https://docs.google.com/document/d/1VbVT1gBLjbsRo0ajkvlXy434tjyOlvx87Q-hRScNbpo/edit) doc.
- If it relates to a failing or flaky test, it should have **kind/failing-test** or **kind/flake** set. These issues are regularly triaged by our SIG Node CI Signal subproject, so you can skip them.
- If it is a bug, it should have **kind/bug** set. Proceed with the next step, [Ensure bug is up to date](#Ensure-bug-is-up-to-date).

#### Ensure bug is up to date

Sometimes, a bug was fixed and didn't get closed. Read through the issue and any linked PRs, and feel free to close the bug if the problem looks like it's been addressed, with an explanation why. For example,

This bug appears to have been addressed now that #12345 has merged.

/close

#### Ensure bug is still relevant

You should ensure that issues are applicable to the [current supported versions](https://kubernetes.io/releases/) of Kubernetes and other components (e.g. Docker, containerd, cri-o).

If the bug does not affect a supported version, or is irrelevant for some other reason, you can close it.

Here is an example of a closed bug that was no longer relevant: https://github.com/kubernetes/kubernetes/issues/23816#issuecomment-864276008

#### Ensure bugs have sufficient information

- If kubelet/container runtime logs are not provided, it will not be possible to debug node issues.
- If there is not a description of how to reproduce the issue, it will not be possible to debug the issue.

If the issue is extremely vague, you may close the issue:

This bug doesn't seem to have enough details to reproduce or further investigate. You must include your cluster version, the container runtime, kubelet logs, and any relevant Kubernetes manifests along with clear steps to reproduce so we can help with your issue.

Please re-open this bug once you have provided more information.

/triage needs-information
/close

If reported bug looks important, but is missing critical information, mark it as un-triaged, set the **triage/needs-information** label, and ask the reporter to add details:

SIG Node is reviewing and triaging issues that are relevant to supported versions of Kubernetes as part of a bug scrub.

This bug doesn't seem to have enough details to reproduce or further investigate. You must include your cluster version, the container runtime, kubelet logs, and any relevant Kubernetes manifests along with clear steps to reproduce so we can help with your issue.

Once more details are provided, the bug will be accepted.

/triage needs-information

### Confirm the bug is correctly labeled

Make sure bugs are marked with the appropriate SIG. Remove from SIG Node if bug doesn't belong here (`/remove-sig node`) or add co-owned SIG for their visibility (e.g. `/sig storage`). If you're not sure if a bug affects SIG Node or not, ask a mentor for help.

Ensure that the bug's steps to reproduce are up to date and applicable to the [current supported versions](https://kubernetes.io/releases/) of Kubernetes. Accept the bug with (`/triage accepted`). If you believe the bug needs to be confirmed on that latest version, you can attempt to reproduce the issue yourself, and post a confirmation, or if the reproducer steps are unclear, ask the reporter for the more information. Text may be as follows:

SIG Node is reviewing and triaging issues that are relevant to supported versions of Kubernetes as part of a bug scrub.

This bug was reported against an old, unsupported version of Kubernetes. Please let us know if it can still be reproduced on a [supported version](https://kubernetes.io/releases/).

Once more details are provided, the bug will be accepted.

/triage needs-information

### Good first issue bugs

Many new contributors struggle to find a good first issue to work on. If the issue is well scoped and has enough details, or if you can provide such details, mark it correspondingly. Mark issue as "help wanted" (`/help`) and/or "good first issue" (`/good-first-issue`). Review the [good first issue](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md#good-first-issue) guidelines for more information.

### Bugs resolved by documentation

Some issues can be resolved by providing clearer documentation. These may be "as designed" issues where the behaviour needs to be clearly spelled out in Kuberenetes docs, or issues that have an easy work around that should be used instead of complex code changes.

For such issues, check to see if a bug has also been [filed against the website](https://github.com/kubernetes/website/issues) and link it back to the original issue. You can close the original issue as a duplicate if it is already listed.

If there is not a website issue, add a `/kind documentation` label and provide next steps on what to document. The issue can then be addressed by a PR to the Kubernetes Website.

### Setting bug metadata

Bugs reported for the features that are currently in alpha/beta stage should be linked to the corresponding KEP issue (`KEP: kubernetes/enhancements#281`). Associating bugs with KEPs helps to ensure that features are graduated with the high quality. You can add the link by posting a comment that links to the relevant KEP.

Check the area the bug is assigned to and apply more areas if necessary. Here is the list of the most common areas assiciated with the SIG node:

- /area cadvisor
- /area kubelet
- /area kubelet-api
- /area node-lifecycle
- /area node-e2e
- /area docker
- /area test
- /area upgrade
- /area code-organization

You can read more on labels in Kubernetes [here](https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs).

### Triage labels

Once the bug is ready to be worked on and has been confirmed as a valid bug, mark it `/triage accepted`.

Note that only [Kubernetes org members](https://github.com/kubernetes/community/blob/master/community-membership.md#member) can apply this label. If you cannot apply it, ask a mentor for help.

### Fixing the bug

As per any good triage session, sometimes it is easier to fix the bug yourself than to leave it for someone else to follow up on!

Once a bug (**kind/bug**) has the **triage/accepted** label, feel free to work on fixing it. You may need to submit a PR to kubernetes/kubernetes, to the website, to our test infrastructure, or some other repo. Contact a mentor for help.

## Support Requests

The Kubernetes project does not use the issue tracker in kubernetes/kubernetes for support requests. If you have determined that an issue is asking for help, please mark the issue as a support request and close it, as follows:

Kubernetes does not use issues on this repo for support requests. If you have a question on how to use Kubernetes or to debug a specific issue, please visit our [forums](https://discuss.kubernetes.io/).

/remove-kind bug
/kind support
/close