Strategy for handling support requests in k/k

[ehashman]

trafficstars

Right now, when I categorize an issue as kind/support in kubernetes/kubernetes, I usually don't look at it again. I'd love to help these folks, but my focus is mostly on triage and getting bugs fixed.

We see a lot of issues where a support request is initially filed as a bug, and then a triager re-categorizes it as a support request, and then it usually rots out unless someone is feeling particularly helpful. There are currently 45 open support requests, and potentially more that were misfiled but haven't been triaged: https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fsupport

It would be great if, when an issue is categorized as a support request in k/k, we could direct the author to the right support channels. Perhaps a bot could send them some links and close the issue. We may also want to discourage filing support requests against k/k at issue creation time by linking them elsewhere (e.g. Slack/Discourse).

[ehashman]

/cc @mrbobbytables

[ehashman]

/sig contribex

[k8s-ci-robot]

@ehashman: The label(s) sig/contribex cannot be applied, because the repository doesn't have them

In response to this:

/sig contribex

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ehashman]

/sig contributor-experience

[mrbobbytables]

/assign @mrbobbytables @cblecker @nikhita @alisondy For input 👍 /area github-management

[nikhita]

We have a response template for support requests - https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#user-support-response-example. However, we don't autoclose issues today.

We could perhaps do this:

• Remove the Support Request template from here - https://github.com/kubernetes/kubernetes/issues/new/choose
• Add a note below the templates to point to support channels (discuss.k8s.io)
• If someone creates an issue without using the existing templates and labels the issue as kind/support, the bot will comment with the response template and autoclose the issue.

[mrbobbytables]

Remove the Support Request template from here Add a note below the templates to point to support channels (discuss.k8s.io)

We could update our issue templates so the support button will actually take them right to discuss. ref: https://github.com/kubernetes/community/issues/5261

I think it might be worth doing the same thing for enhancement requests there too, except redirect them to the k/enhancements repo

If someone creates an issue without using the existing templates and labels the issue as kind/support, the bot will comment with the response template and autoclose the issue.

Some people do usekind/support (at least in other repos), it might be worth it as a separate command where folks could potentially add their own text (similar to the welcome bot) and have the ability to specify if it will close the issue automatically or not.

[mrbobbytables]

The update for the issue template has been rolled out 👍 https://github.com/kubernetes/kubernetes/issues/new/choose

[nikhita]

Some people do usekind/support (at least in other repos), it might be worth it as a separate command where folks could potentially add their own text (similar to the welcome bot) and have the ability to specify if it will close the issue automatically or not.

/assign I'll take this on and also try to do something similar for kind/feature - https://github.com/kubernetes/kubernetes/pull/98867

[nikhita]

Some people do usekind/support (at least in other repos), it might be worth it as a separate command where folks could potentially add their own text (similar to the welcome bot) and have the ability to specify if it will close the issue automatically or not.

Created https://github.com/kubernetes/test-infra/pull/20868

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

[ehashman]

/remove-lifecycle rotten

Would appreciate some guidance on this as we are about to triage a bunch of node bugs and are likely to mark a bunch of them as support requests.

I will add an agenda item to SIG Node to see how we want to handle them within our SIG; perhaps we can make a template to point people at official support channels and close them.

[spiffxp]

/milestone v1.23 I think a template message that can be copy pasted would be appropriate. Could add a k8s-triage-robot job to comment it with a /close to issues triaged as support

What is the specific ask here, for this team to write the template? I would prefer kicking that back to the broader SIG Contributor Experience folks

Or do we want to push forward with https://github.com/kubernetes/test-infra/pull/20868?

[spiffxp]

/priority backlog Because it's not clear to me what the actionable request is

[ehashman]

I added a template default reply to my GitHub account that I've been using to close support requests (that are often filed as bugs) against SIG Node in k/k:

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

It's really up to ContribEx if we want an overall strategy for these rather than handling SIG by SIG. :)

[k8s-ci-robot]

@ehashman: Those labels are not set on the issue: kind/bug

In response to this:

I added a template default reply to my GitHub account that I've been using to close support requests (that are often filed as bugs) against SIG Node in k/k:

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

It's really up to ContribEx if we want an overall strategy for these rather than handling SIG by SIG. :)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@ehashman: Closing this issue.

In response to this:

I added a template default reply to my GitHub account that I've been using to close support requests (that are often filed as bugs) against SIG Node in k/k:

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

It's really up to ContribEx if we want an overall strategy for these rather than handling SIG by SIG. :)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ehashman]

lol bot

/remove-kind support /reopen

[k8s-ci-robot]

@ehashman: Reopened this issue.

In response to this:

lol bot

/remove-kind support /reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[MadhavJivrajani]

/remove-lifecycle rotten /lifecycle frozen I brought this up in the last contribex meeting and had some ideas around this, I'll collate them into an RFC in the next couple of days.

[sftim]

I'd really like a bot to handle the case where something is mis-triaged as support, and the submitter wants to let us know. Once we have a bot to fix mistriage, we can be more vigorous at automating handling of the remaining issues where the issue submitter either agrees it's a support request, or we don't hear from them further.