Closed MadhavJivrajani closed 1 year ago
I'd support this change. If we can find a way to "move" this somewhere else, it would be great! (also may be we should look more at GH discussions?)
+1 from me
Might also be worth considering how to best handle redirecting confused users filing what are essentially really requests for support of various commercial offerings.
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
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
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.
This bot triages un-triaged issues 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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Please note that this discussion is intended only for issues coming into k/k
What Is The Intent/Goal Here?
Setting the context for the "why" The TL;DR of the intent of doing something like this is: better the experience of when an issue is autoclosed, more info and details below!
Handling
kind/support
Issues In k/kCurrent State
There are a non-trivial number of support issues that are opened in k/k, ideally - support issues are to be raised in the Kubernetes Community Forums, but either due to less visibility or lack of awareness that the forums exist, these issues are opened in k/k.
The support issue template in k/k links to the forums after https://github.com/kubernetes/community/issues/5261, but issues are still filed under
kind/bug
.If opened in k/k, there might be some discussion that might or might not answer the author's query after which the issue continues to remain open. This is where the triage bot comes into play. If the author's query was answered, then after 30 days,
lifecycle rotten
and autoclose occurs, which might not be so bad because the query is answered. But more often than not, the query isn't completely answered, after which autoclosing might cause friction or the author removes the lifecycle labels and the same thing might repeat. Additionally, the bot message being generic for issues/PRs does not provide enough information to the author for what they can do next to better reach out to folks for help.Please note that these issues don't always stay open, sometimes the author ends up closing them, and some SIGs such as sig-node actively cleanup support requests as part of their triage processes.
Proposed Change
When an issue in k/k is marked as
kind/support
:sig/foo
labels are applied on the issue that has akind/support
label, the bot comments with a link to the K8s slack as well as the relevant sig channels (based on the sig labels that exist) +#kubernetes-users
along with links to the k/community READMEs for those sigs, so that the author is aware of what the potential next steps could be.Prior Work
There have been active discussions around this such as:
Misc
This was discussed in the last contribex meeting, meeting notes can be found here.
/cc @ehashman author of original issue in k/community /cc @kubernetes/owners /cc @jberkus @nimbinatus @parispittman @dims - fyi /sig contributor-experience /area github-management /assign