automatically lock old issues/PRs

[Luap99]

I suggested this before but we never made any progress on this.

I propose we automatically lock all closed old issues and PRs. IMO issues and PR should be locked after 90 says of inactivity.

Reasoning: As a maintainer for a while now I get almost everyday notifications for comments on old issues (sometimes PRs). These can be grouped into three categories:

• 80% useless or off topic comments, comments that add no value at all. Examples for this are: I have the same problem or <paste some unrelated error message> without any additional info
• 15% comment that may be useful. Example: I run into error xxx with version (some recent version). In most cases these are different bugs and should be reported as new separate issue.
• 5% actual related to the original issue and using a recent issue, either some form of regression or different corner case to trigger the same bug.

Percentages are based on my subjective feeling and not real measurements.

I think all of these cases are better handled in a new issue with all requested information. This makes sure that a) A maintainer will take look as we triage all new issues. b) The original participants are not spammed with possibly unrelated comments.

So far I found https://github.com/dessant/lock-threads which seems to do what I want.

A list of issues/PRs that this would effect as of today: https://github.com/containers/podman/issues?q=is%3Aclosed+is%3Aunlocked+updated%3A%3C2023-04-01+
Of course the date is variable. I think 90 days is a good limit. I also repeat that this only effects closed issues/PRs. I do not want to auto-close issues just because there are stale.

I am opening as a discussion here so everyone (i.e. non maintainers) can give their opinion if they want.

[cevich]

dessant/lock-threads LGTM and seems easy to implement.

[rhatdan]

I am fine with the idea,

[mheon]

I am perfectly fine with this.

[flouthoc]

I think only bugs should be locked not RFEs

[mheon]

IMO we shouldn't even worry. Closed issues are closed issues, RFE or bug doesn't matter. If an RFE was closed without code being merged it's probably because we actively decided not to do it.

[edsantiago]

I don't understand the "not RFEs" comment. I'm going to take a wild guess that it was a temporary confusion between closing and locking? @flouthoc was that what you meant? Can we dismiss this? If you truly meant your words exactly as you wrote them, would you mind justifying?

[flouthoc]

@edsantiago I meant that there are some feature requests which are not given priority or were not possible to implement at that moment of time frame, so they keep sitting in issues. However if we lock such issues it will remove the possibility of adding more comments to such issues from community members, my idea was just to keep RFE's open so folks can comment and still show interest and discuss possibility ( Irrespective of the time frame when a RFE was created )

[Luap99]

I propose we automatically lock all closed old issues and PRs

We are only talking about closed issues here. We should never auto-close issues automatically. If an RFE is open we have interest in it, if anyone closed it it means we do not want it so we can lock it as well. If a user later wants to add something they can just open a new issue.

[flouthoc]

Sounds good to me then.

[vrothberg]

I am on board as long as there's a message that asks to open new issues if users still see the issue after the fix.

[cevich]

Does anyone know if locking of the comments also results in an e-mail? Hopefully not.

[Luap99]

Reading the docs I don't think so but we can test it easily. I locked #18139 as test so you can tell me if you got a email for it.

[vrothberg]

Maybe we can drop a comment when a PR gets merged / issue gets closed? That will avoid the trouble of getting messages on old issues/PRs.

[...] just put it in CONTRIBUITING or Readme doc

I wouldn't like this experience as a user. Facing a bug is usually a stressful/annoying moment. A useful comment/instruction on the issue/PR would give me direct guidance. But it would be unlikely for me to read the entire README or contributing guidelines.

[Luap99]

Maybe we can drop a comment when a PR gets merged / issue gets closed?

But that will still generate one extra notification for everyone but yeah I agree that it would be less of an issue if we get it directly when the issue is closed or PR is merged.
But the problem with that is that the mentioned tooling does not support it so unless we find something which does we would need to write our own.

I wouldn't like this experience as a user. Facing a bug is usually a stressful/annoying moment. A useful comment/instruction on the issue/PR would give me direct guidance. But it would be unlikely for me to read the entire README or contributing guidelines.

That is a fair point but I don't see a good way around that. If the issue is locked the users is unable to comment so what you do in such situation? For me the only logical things would be to file a new issue (and hopefully the users then will provide the requested information) or the user realizes that they have nothing useful to add and just don't comment. Ideally a user at that point would start reading our docs (I can dream right?).

What we can do with the tooling is to add a label, this will also not send notifications. We could add a label like:
locked - please file a new issue

[cevich]

I locked #18139 as test so you can tell me if you got a email for it.

Thanks for testing this, indeed I did not receive any e-mail for this.

with the tooling is to add a label, this will also not send notifications.

That's a fantastic idea actually.

[TomSweeneyRedHat]

I concur with @vrothberg

[cevich]

At this point it seems the consensus is:

• Use dessant/lock-threads in a new workflow to automate this.
• Run the workflow daily at some time (any preference?)
• Lock closed issues and PRs after 90-days (since closing)
• Chuck on a (new) locked - please file a new issue label.

Am I missing anything?

[cevich]

Oh, also: Is it worth testing this workflow on a dummy-repo. first?

(I'd have to create a handful of issues, close a few, then wait at least a day or two).

[Luap99]

Having a small test setup sounds good, while I don't see anything critical here it is always better to test it first.

[edsantiago]

A simple safety protocol might be to set *-inactive-days to 1825 (5 years). That will (should) lock 48 issues.

[cevich]

I don't see anything critical here it is always better to test it first.

Context: The way this GHA has to be implemented in a workflow, it's impossible to verify it works (at all) before being merged into main.

A simple safety protocol might be

My fear is more that this is a community authored action and we'd be letting it "borrow" repository-write permission 🤔. Ref. marketplace page w/ disclaimer:

Lock Threads is not certified by GitHub. It is provided by a third-party and
is governed by separate terms of service, privacy policy, and support documentation.

I've trolled through the source briefly, but it's written in javascript and I'm definitely ignorant there. It's probably "okay" (40 forks, 273 stars, recent issue/PR activity), but certainly less trustworthy than something authored by github.

I generally steer away from being a "safety nanny" but in this case I'm leaning toward doing a test on automation_sandbox first. Please feel free to disagree if you think I'm being paranoid.

[cevich]

Opened jira card RUN-1868 for this.