Gregory's Server@jcsteh @svenja Also, several maintainers have confided that issues are becoming a source of anxiety, because the attitude of FOSS users completely turned around in two decades.
In the 2000s, you requested features by writing to the development mailing list, with an expectation of "default no, unless a dev wants to pick it up". Now, the GH issues UX implies a "default yes" as you can directly write into the project's roadmap, and devs have to close issues to reject them.
A vocal minority of users come with a strong entitlement and are a pain to interact with. As a maintainer, you're open to a wide spectrum of risks, from belittlement, to insults, to angry internet mob. In this context, it's easier to allow the stalebot to close issues instead of risking angering someone who will harass you. This is even worse for #neurodivergent maintainers (a lot of us are) who experience rejection sensitive disphoria.
@quinze @jcsteh @svenja I'd suspect a stalebot is more likely to nuke an issue related to accessibility simply because that takes longer to do, even should the dev actually be interested in it, and also because many of them, sometimes rightly even, prioritize otherthings over it, like critical bugs that break the program entirely. This intersects with the whole accessibility is not a feature thing of course so there's a whole range of views on the exact priority listing, but that's not as relevant for my point. You don't want users that need accessibility to be constantly flooding your issue asking for updates on something everybody, including them, knows will take a while. But if they don't, and you don't, then it's gone, and now it's out of sight, out of mind, closed issues are stupidly numerous, so if something goes there odds are you just won't look at it again.
@quinze @jcsteh @svenja I'd suspect a stalebot is more likely to nuke an issue related to accessibility simply because that takes longer to do, even should the dev actually be interested in it, and also because many of them, sometimes rightly even, prioritize otherthings over it, like critical bugs that break the program entirely. This intersects with the whole accessibility is not a feature thing of course so there's a whole range of views on the exact priority listing, but that's not as relevant...