Drop prow issue autoclosing

[VannTen]

We're currently auto-handling issues "lifecycle" with Prow. -> autoclosing issues without activity.

I think we should (re?)examine that policy, for reasons similar to https://github.com/kubernetes/kubernetes/issues/103151

Pros of auto-closing issues:

• Keeps number of issues small
• ... (please edit or suggest other because I do not see many benefits myself)

Cons:

• Noise. stale -> rotten -> close makes 3 notifications an
• Low information
• Require manual intervention to avoid it. (/lifecycle frozen)

Some metrics:

$  gh search issues --owner thoth-station --label lifecycle/frozen --state open

Showing 30 of 128 issues # currently manually frozen

...

$ gh search issues --owner thoth-station --label lifecycle/rotten --state closed

Showing 30 of 296 issues # presumably closed by prow over the whole project
lifetime

Ultimately, it seems to me the signal to noise ratio is pretty poor. Triage-party/github api queries looks like a much better tool, more finegrained and without the time threshold effect.

@codificat @goern

[VannTen]

Not sure what sigs should be concerned by this... The hypothetical dev-experience maybe ?

[VannTen]

Another note: Auto-closing could maybe be more relevant in specific cases, for example:

• issues asking for more information (unconfirmed bugs for example) without activity
• Untriaged issues for a long time (the rationale being that untriaged issues lack context and it would probably less effort to create a new one when the problem/suggestion surfaces again)

[VannTen]

/kind discussion

[sesheta]

@VannTen: The label(s) kind/discussion cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/thoth-station/core/issues/456#issuecomment-1237933886): >/kind discussion 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.

[VannTen]

@goern @codificat (as I've seen you used many /lifecycle frozen I think) Thoughts ?

[goern]

/sig user-experience /kind feature

[KPostOffice]

Just stumbled upon this. I think this makes a lot of sense, as soon as something is seen as a valid extension or bug it shouldn't be automatically be deleted. Something is marked with triage/needs-information can probably be safely auto closed if it hasn't been interacted with after a certain amount of time. Other than that, untriaged issues usually represent a lack of interaction or understanding and should be commented on and given the label "accepted" or given the label "needs-info", not auto closed.

TLDR: only apply lifecycle to issues that require more info that haven't received interaction

[KPostOffice]

Actually, looking at the labels we have for our projects there are a few others that make sense: triage/duplicate/triage/unresolved: give users time to disagree with duplicate label or why issue should be resolved (~5-10 days) triage/needs-information/triage/not-reproducible: recognizes the potential of the issue raised, but needs more info before it can be accepted. Without interaction it will be auto closed, but give more time (~30-60 days)

After a new comment remove triage label (issue needs to be interacted with again)

[VannTen]

/triage accepted (Per the thoth tech talk meeting). /lifecycle active /assign