Open ehashman opened 3 years ago
/cc @mrbobbytables
/sig contribex
@ehashman: The label(s) sig/contribex
cannot be applied, because the repository doesn't have them
/sig contributor-experience
/assign @mrbobbytables @cblecker @nikhita @alisondy For input 👍 /area github-management
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:
Support Request
template from here - https://github.com/kubernetes/kubernetes/issues/new/choosekind/support
, the bot will comment with the response template and autoclose the issue.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.
The update for the issue template has been rolled out 👍 https://github.com/kubernetes/kubernetes/issues/new/choose
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
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.
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
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
/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.
/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?
/priority backlog Because it's not clear to me what the actionable request is
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. :)
@ehashman: Those labels are not set on the issue: kind/bug
@ehashman: Closing this issue.
lol bot
/remove-kind support /reopen
@ehashman: Reopened this issue.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/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.
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.
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).