@quinze@svenja I tend to think (but I obviously don't have evidence) that this is more about our society's obsession with superficial statistics, trends, algorithms, etc. If you have a high ratio of open issues, your project looks "worse" than some other project which has a lower ratio.
@jcsteh@svenja Interesting. I have contributed to FOSS projects (commercial and non-commercial) since 2003, and I don't recall stalebots being a thing before GH. Now that they made that practice widespread, there's a "social contagion" to other non-GH-hosted projects, for sure.
Debian, KDE, Gnome, Mozilla don't have stalebots, but it's not all rosy. For example, the KDE bugzilla was known to be a "scream into the void" place, until the KDE Bug Squad was formed to triage issues and reduce the friction for developers to engage with them. So far this has been a great success, but it requires people to help.
Also, there's a case for declaring "issue bankruptcy" a few times per decades, for example after a major rewrite. I would take less offense if issues were closed after a year, but 30 days is completely nuts indeed.
@jcsteh@svenja Interesting. I have contributed to FOSS projects (commercial and non-commercial) since 2003, and I don't recall stalebots being a thing before GH. Now that they made that practice widespread, there's a "social contagion" to other non-GH-hosted projects, for sure.
Debian, KDE, Gnome, Mozilla don't have stalebots, but it's not all rosy. For example, the KDE bugzilla was known to be a "scream into the void" place, until the KDE Bug Squad was formed to triage issues and reduce the friction...
@quinze Yeah, I could live with a year. Having to bump an issue after a year to say "yeah, re-tested, still relevant" doesn't seem like an unreasonable burden. @svenja
@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.
@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.
@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...
@quinze@jcsteh@svenja That is, some kind of triage is useful, and the stalebot should straight-up ignore triaged issues! SO as long as someone is looking at the incoming issues and marks this as going to get done, the bot says OK, this issue shall stay open until you close it yourself.
if you have a high ratio of open issues, your project looks "worse" than some other project which has a lower ratio.
Really true, but I link it back to "real bugs, unconfirmed bugs, feature requests and backlog items being into a single list".
When evaluating a project, I indeed want to confirm that there's no important bug, but I don't care about 100 pending feature requests for edge cases. Bugzilla, Trac, Youtrack... all come with default "severity" fields, GH issues do not.
But indeed, perception of projects has been completely warped, including idiots opening "is this project dead" issues because a project had no commits for a few months. A project can be complete and done, with only security fixes.
if you have a high ratio of open issues, your project looks "worse" than some other project which has a lower ratio.
Really true, but I link it back to "real bugs, unconfirmed bugs, feature requests and backlog items being into a single list".
When evaluating a project, I indeed want to confirm that there's no important bug, but I don't care about 100 pending feature requests for edge cases. Bugzilla, Trac, Youtrack... all come with default "severity" fields, GH issues do not.
Gregory's Server
@quinze @svenja I tend to think (but I obviously don't have evidence) that this is more about our society's obsession with superficial statistics, trends, algorithms, etc. If you have a high ratio of open issues, your project looks "worse" than some other project which has a lower ratio.