Post AsRAcpwFDI7keGj3M8 by Conan_Kudo@fosstodon.org
(DIR) More posts by Conan_Kudo@fosstodon.org
(DIR) Post #AsQwXs7sFntQcvu6Bk by cassidy@mastodon.blaede.family
2025-03-26T03:08:21Z
1 likes, 1 repeats
I get that issue trackers are hard, but I feel like stale bots that *close issues* come off as so hostile. I shouldn't have to come back to the issue tracker every month to confirm, “Yes, this is still an issue!” to prevent the issue from getting closed.Tag an issue as “stale” for easier triage—that’s fine! But “oops you aren’t engaged enough, sorry, your issue doesn’t exist anymore” feels like a bit of a slap in the face. Especially if it gets closed as “not planned.”
(DIR) Post #AsQwY0Hjv0XPvqa5g0 by cassidy@mastodon.blaede.family
2025-03-26T03:11:42Z
0 likes, 0 repeats
I guess it's possible the issue gets accidentally fixed or becomes irrelevant, but something about *closing* a perfectly valid issue report because nobody from the project could come by to check it out rubs me the wrong way. In a similar way that closing an issue as “WONTFIX” does.It really turns me off as a potential contributor who is trying to help, and makes it less likely that I would actually stick around and help with that much needed issue triage.
(DIR) Post #AsR5IMHjFsVh7LBt7Q by cassidy@mastodon.blaede.family
2025-03-26T04:36:19Z
0 likes, 0 repeats
@mattdm ha, I didn't know Fedora did this! It's not an uncommon pattern, but I think it could be tweaked to be just as useful to maintainers while being more welcoming to issue reporters.A simple solution could be to label *untriaged* issues as stale (or better: “Needs Attention”) after some time of inactivity with a gentler comment about, “Sorry we haven't been able to triage this. If you know it’s still an issue in the latest release, feel free to comment to help us triage it.”
(DIR) Post #AsR5INQd0HDsfEMVd2 by BrodieOnLinux@mstdn.social
2025-03-26T04:52:40Z
0 likes, 0 repeats
@cassidy @mattdm I think filtering based on whether there has been sufficient information provided, along with sorting based on when the last comment on the thread was made would go a long way in mitigating the issue. Nothing really will solve it without having people constantly going through and triaging old issues.
(DIR) Post #AsRAcpwFDI7keGj3M8 by Conan_Kudo@fosstodon.org
2025-03-26T05:52:25Z
0 likes, 0 repeats
@BrodieOnLinux @cassidy @mattdm I think there's a difference between Fedora's stale bug closure and what people do on GitHub. We auto-close bugs in RHBZ that target Fedora releases that are EOL. We automatically comment on those bugs informing them of why and tell them how to reopen it.That's a lot kinder than the GitHub stale bots which aggressively close them in 60/90 days and tell you nothing.
(DIR) Post #AsSavWXeLVPXxWkkM4 by BrodieOnLinux@mstdn.social
2025-03-26T22:21:54Z
0 likes, 0 repeats
@Conan_Kudo @cassidy @mattdm I think that's a bit more reasonable given the gap between releases
(DIR) Post #AsTvH4Lo24qJ8dixDU by ity@estradiol.city
2025-03-26T03:19:01Z
1 likes, 0 repeats
@cassidy Yea, I mean I stop using projects that close my reports as stale lol
(DIR) Post #AsUIfNCzrv5nWMA5s8 by glyph@mastodon.social
2025-03-26T21:30:32Z
0 likes, 1 repeats
@cassidy "stale" is also a non-actionable category. There are two distinct states here: one is "the project is overwhelmed, and nobody can respond". The other is "the project requires more information from the reporter, and the issue is incomplete and cannot be actioned otherwise". These require *opposite* remedies! If the project is overwhelmed, everyone needs to be quiet. If the report is incomplete, everyone needs to chime in. Close-as-stale bots are worse than useless!