ci: stop the stalepocalypse 🤖

[justlevine]

What does this implement/fix? Explain your changes.

This PR changes the stalebot configuration to no longer automatically close issues, preventing the quarterly "stalepocalypse", where dozens of issues are unceremoniously closed, flooding maintainers with a deluge of notifications, and forcing them to comb through them all or risk them being swept under the rug for good.

Once merged, the following changes to the "triage flow" will take effect:

1. Immediately: the stale label will be deleted and replaced by stale? on existing issues. (manual task: assigned to @justlevine )
2. After 90 days, issues with no activity will be marked stale?.
3. New activity on a stale? issue will automatically remove the stale? label.
4. Contributors can triage stale? issues by removing the stale? label manually, closing as invalid or wontfix, or progressing the issue until it earns one of the exemptLabels (e.g. ready for review, status: blocked, etc). Note: the not stale label should be reserved for long-term milestones or evergreen issues that are unlikely to be invalidated by a separate issue/PR, and not just to short-circuit the stalebot checks.
5. Contributes can ignore/hide issues with the stale? label by filtering the issue tracker / project.

Does this close any currently open issues?

Revisits #2494

Any relevant logs, error output, GraphiQL screenshots, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

Any other comments?

The argument in a nutshell is:
Premises:
1: There are so many issues in the backlog, it makes triage and prioritization a nightmare.
2: Many issues are low-priority wontfix-es that can only be implemented if someone decides to prioritize the work on it.
3: We have limited resources (contributor hours) both in terms of issue triage and exploring/submitting actual PRs.

Arguments for autoclosing:

• Instead of wasting time pruning our issue list, we can take the prolonged lack of activity on an issue as an indicator we dont have the resources to implement it, and close it automatically.
• If the issue gains traction in the future, it can always be reopened.

Arguments against:

• The time we 'save' closing stale issues we lose having to triage closed issues (every comment requires an evaluation of whether to reopen or direct the the user to fill out a new issue), and retriage stale issues every 90 days (or risk them getting closed).
• It discourages user contribution (users searching/commenting/filing issues don't know why their issue wasn't prioritized; new users coming from search dont know if an autoclosed issue was later addressed or still relevant; new contributors with varying skillsets don't have obvious candidates since issues that go stale are often the ones where the current contributors arent "able" to handle easily.
• It reduces the number of non-semantic labels we need to juggle (theres no practical difference between stale? and stale, and the not stale label can itself go stale, so its only use is for shortcircuiting the check, and there's semantic statuses that are better suited to it if we dont need to worry about the issue getting closed and dissappearing).
• It give a false impression of the project's status by changing issue counts to be a metric of contributor availability.
• The "benefits" of closing the issue for maintainers aren't much different than just hiding the stale? label from the issue/project view.

Where has this been tested?

Operating System: N/A

WordPress Version: N/A

[codeclimate]

Code Climate has analyzed commit 5f6cea6 and detected 0 issues on this pull request.

View more on Code Climate.