In v3 several input parameters where renamed and since v4 it requires Node.js 16.
This resolves warnings about Node.js 12 and `set-output` being deprecated and
slated for removal in the `Lock threads` workflow.
This file should be modified through pull requests.
This reverts commit bc71f0937b5eb8399e29bd8281974bb43beb4b4e.
This reverts commit 99cac0b1b90eb669cac6321c3b288510ad285168.
This reverts commit 0f0da3c3d86a438e208d5efe5e51deaa7e9512f8.
It is 1 whole year, for an already closed issue.
Any "engagement" that happens at that point is irrelevant to the
original issue at hand, and a new issue should be opened instead.
Increasing the grace period even further is even less likely to be helpful.
The point here is to let issues be *done*, and have any *new*
discussions happen in *new* issues so you can decouple the context.
This revert pending further discussion.
Set locked thread inactivity count to default 365.
Add 'needs more info' as an obvious on its face exception.
The default seems quite an inconventient, very strict thing t do:
it will lock threads that are closed and quiet because they have
been quiet and closed. This seems to make it hard to talk about
issues after they are closed or contribute. I can as a fish-shell
contributor, but that's not really the point.
Practically, right now to reply to any PR or any issue fixed in
July, well you can't.
We've been getting a bunch of comments on old closed issues. Instead
people should create new ones.
This adds a github "workflow" that should lock closed issues/prs after
90 days, except those labelled "question".
Let's see how it works out.
