[RFC] Better Handling Support Requests In k/k

MadhavJivrajani commented 2 years ago

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/k

Current 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:

The issue is automatically exempted from the issues the triage bot cares about for putting lifecycle labels
The issue gets a fixed 30 day period after which it will be autoclosed
- Why not close immediately?
- Because some issues might not be support-related at all (example), a good way to bring about that realization is to allow the conversation to happen for some amount of time. If within this time, it turns out that the issue might be a bug or a feature request, the label can be removed and the issue then follows the lifecycle of any other issue.
- Another reason is that the issue might just get enough support then and there from other folks in the community, and that should be allowed to happen.
If sig/foo labels are applied on the issue that has a kind/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.
When autoclosing after 30 days, instead of the generic message of "not enough contributors", we could provide a better-worded message (perhaps the support template) with more context and information.

Prior Work

There have been active discussions around this such as:

Some of what I've described above has been discussed here: https://github.com/kubernetes/community/issues/5435
Implementation similar to the bot labeling behavior described above: https://github.com/kubernetes/test-infra/pull/20868
https://github.com/kubernetes/community/issues/5261

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

dims commented 2 years 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?)

jberkus commented 2 years ago

+1 from me

BenTheElder commented 2 years ago

Might also be worth considering how to best handle redirecting confused users filing what are essentially really requests for support of various commercial offerings.

k8s-triage-robot commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

/remove-lifecycle rotten

k8s-triage-robot commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

/remove-lifecycle rotten

k8s-triage-robot commented 1 year ago

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 commented 1 year ago

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:

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 as fresh with /remove-lifecycle rotten
Close this issue with /close
Offer to help out with Issue Triage

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

/lifecycle rotten

k8s-triage-robot commented 1 year ago

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:

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:

Reopen this issue with /reopen
Mark this issue as fresh with /remove-lifecycle rotten
Offer to help out with Issue Triage

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

/close not-planned

k8s-ci-robot commented 1 year ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes/test-infra/issues/25048#issuecomment-1477112365): >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: >- 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: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

kubernetes / test-infra