Email or username:

Password:

Forgot your password?
Jamie's posts Post Back to profile
Top-level
Jamie Teh

@svenja Some people have argued that it helps reduce clutter and brings issue counts down to more manageable levels for developers. I think that's an invalid argument; the bugs don't go away just because you close them. You're just pretending they do. It's fine to say "we don't have the time to fix all of these things", particularly for volunteer projects, but I don't understand why you'd want to delude yourself that there are less bugs than there are. If my project has 5000 open bugs, that's unfortunate, but that's also life.

17 October at 7:45 | Open on aus.social
12 comments
Svenja

@jcsteh Yeah, also this. I'd rather see them saying "we can't reproduce it" than just closing it.

17 October at 7:46 | Open on mstdn.games
Jamie Teh

@svenja So sometimes, I think closing because you can't reproduce is valid. If only one person ever experiences a bug and it can't ever be reproduced by anyone else ever, that's not actionable and it will never be actionable, so leaving it open doesn't serve any purpose. My problem is with stale bots that close things just because no one has commented for some number of days. Maybe it just took the developers longer to find the time to investigate it than that.

17 October at 7:48 | Open on aus.social
Svenja

@jcsteh Yeah, I agree on that, but they just closed my Issue without saying they can't reproduce.

17 October at 7:53 | Open on mstdn.games
Quinze Plush

@jcsteh @svenja Agreed. And nobody talks about the real root cause of stale bots: Github issues are completely inadequate for managing a software project's development:

- bugs, feature requests and the real roadmap items are mixed up in a single flat list
- no standardized triage process (unless you build your bespoke and time-consuming label taxonomy), giving people the impression that everything there will be done. So you get passive-aggressive "any news on this?" comments regularly
- no saved views, no advanced filters

GH projects try to fill some of that gap, but oh boy do they have issues!

@jcsteh @svenja Agreed. And nobody talks about the real root cause of stale bots: Github issues are completely inadequate for managing a software project's development:

- bugs, feature requests and the real roadmap items are mixed up in a single flat list
- no standardized triage process (unless you build your bespoke and time-consuming label taxonomy), giving people the impression that everything there will be done. So you get passive-aggressive "any news on this?" comments regularly
- no saved...

17 October at 8:38 | Open on tech.lgbt
Jamie Teh

@quinze @svenja Is that really the root cause though? I've seen that kind of behaviour even for closed source products using Jira, etc.

17 October at 8:43 | Open on aus.social
Jamie Teh

@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.

17 October at 8:45 | Open on aus.social
Quinze Plush

@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...

17 October at 9:11 | Open on tech.lgbt
Jamie Teh

@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

17 October at 9:14 | Open on aus.social
Quinze Plush

@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.

17 October at 9:21 | Open on tech.lgbt
x0

@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...

17 October at 15:10 | Open on dragonscave.space
x0

@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.

17 October at 15:22 | Open on dragonscave.space
Quinze Plush

@jcsteh @svenja

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.

@jcsteh @svenja

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.

17 October at 9:25 | Open on tech.lgbt
Go Up