It's not necessarily true that they 'should' be looked at. Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project.

A middle-ground might be to leave open the issues with recent activity, with the idea being that at least the ones that are affecting people the most are not swept under the rug.

> Most old projects that follow the 'never close without verification' philosophy end up, eventually, with a majority of open issues not actually reflecting the current state of the project.

There's a crucial question here that I find not enough people ask themselves: does that actually matter? And if yes, why? What, specifically, is the material problem caused by this situation?

It often feels like people are just chasing 'inbox zero', under the assumption that "0 open issues == good", without any actual material problem being solved in the process.

(Github probably isn't helping here, with their undeservedly prominent placement of the open issue count driving this sort of behaviour...)

An easy step towards a solution would be for GH to mandate a version number field and allow repo owners to close wildly outdated issues and PRs en masse (like if they just released 3.0, closing all 1.x might be entirely reasonable, and might as well be easy).