The 2022 Language Summit  included a discussion about the issue and PR backlog. The premise was Sam Schillace’s observation that “a large pile of old, low-ish priority bugs […] obscures both newer quality issues as well as the overall drift of the product. It’s far better to resolve something to the right bucket or ‘will not fix’ to keep the tool clean for things that matter.” 
There were a number of interesting suggestions, but not enough time to discuss any of them at depth. In the next few weeks we will be creating a thread for each of the ideas, so that it can be discussed and we can reach a collective decision about which changes we want to implement in our work practices. This is the first in the series.
@pablogsal mentioned in the discussion a problem that I will call “core developer fatigue”, where it is sometimes easier to leave an issue open than discuss the closure decision with the person who reported it. In other words, letting someone down is an unpleasant task, and many low-value issues remain open because we would rather avoid it.
In a slightly different context, @tiran suggested that we create standard explanations for the most common closure reasons, which a core dev can apply without having to type repetitive comments.
I think Christian’s suggestion may actually help not only with reducing the typing workload, but also with the emotional fatigue that Pablo described, because canned responses tend to feel less personal to both sides of the exchange.
We could implement Christian’s suggestion by adding a number of close-reason labels, like close-out-of-date, close-cannot-reproduce, close-unsupported-platform, close-abandoned etc. We can then have a bot that responds to this label by closing the issue with the canned response. The core dev can always add information in an additional comment if necessary.