Skip to content

Strategy for handling support requests in k/k #5435

Open
@ehashman

Description

@ehashman

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).

Metadata

Metadata

Labels

area/github-managementIssues or PRs related to GitHub Management subprojectlifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.priority/backlogHigher priority than priority/awaiting-more-evidence.sig/contributor-experienceCategorizes an issue or PR as relevant to SIG Contributor Experience.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions