If your open source project uses “stale bots” to close issues after a period of inactivity, I am not going to participate in your project.
These bots do nothing to help issues be fixed. What they do is put undue pressure on the author of an issue to come up with a fix themselves, or to discount issues raised by people who are not familiar with the language or toolset used by the project.
I can report a bug, well, without writing a single line of code. If your stale bot closes it, you didn’t want the bug report. Happy to oblige.
@futzle I’ve spent a lot of time in open source both as a user and a maintainer. I’ve had issues closed by stalebot and been frustrated.
But on the other side, as a maintainer of a popular project, I started think it may be a good fit. If literally no one interacts with a ticket for six months, that’s a strong signal of low user impact and low developer interest. It’s the kind of issue I often manually close later. If that work was automated, my time could be higher impact.
@markstos @futzle The problem here is closing an issue for a still-existing problem to begin with, whether it's automated or manual is besides the point really.
An open issue costs nothing if you have a halfway decent workflow (eg. having some kind of sorting metric to prioritize work, and communicating that not all issues may be solved).
@markstos @futzle Here's an extensive guide that suggests some strategies: https://apenwarr.ca/log/20171213
@joepie91 @futzle That’s for commercial teams. Motivating and managing time of volunteers is a different ball of wax.
The solution for open source communities is not for the current volunteers to do even more work, it’s for more volunteers.
Stale bot creates time for volunteers by automating some work. That stale ticket was going to get closed or ignored by a human if not closed by a bot. Sorry.
@markstos @futzle I have read the whole thing. No, it is not just for commercial teams, that is just the context in which it is explained.
I have also been doing open-source development and community management for some 15 years by this point so I understand perfectly well how volunteer work works, thank you.
@markstos @futzle (Also, if you want more volunteers, a good start would probably be to recognize that people submitting detailed bugs are *also* contributors, and not indiscriminately closing their issues without ever resolving them, which is functionally equivalent to telling them you don't care about their work.)
@markstos @futzle
- It allows for people to contribute a solution *eventually*
- It serves as a reference for people newly running into the same bug, especially if workarounds are suggested
- It doesn't communicate "I don't care about your work" (assuming you've communicated expectations correctly)
- It provides more reliable statistics on how well things are going in terms of reliability/support/etc., both to you and to potential contributors
- Closing it will just cause a new bug to be created once the next person runs across it anyways so it doesn't even meaningfully reduce your bugs anyway
Are those sufficient reasons? I'm sure there'll be a couple more reasons not to fudge the data if one thinks about it for a bit
@joepie91 @futzle Most of the projects I volunteer with were written by an author who left the project. I was user who helped out and was given commit rights. Sometimes other users have stepped up and helped too, other times, not.
Some bug reporters seem to have the idea that there's someone behind the curtain who has the time and interest to craft the software to perfection or add endless features. In reality, often one or two volunteers trying to leave things better than the found them.
@markstos @joepie91 I’d like to be untagged from this conversation, please. I’ve been in open source development teams myself and I’m yet to read anything compelling enough to change my mind. Not that I asked anyone to change my mind: my original post was about setting boundaries and it seems that some have taken this as an invitation to convince me to move my boundaries.
@markstos By this point it is clear to me that you are looking to justify your current position, rather than learning about a different one, so I am stepping out of this conversation.
There is not enough time in my day to be arguing with someone who only asks questions and then does nothing with the answers.
@joepie91 @futzle 1. People can still contribute a fix later by finding a closed issue. 2. It's still there for reference. 3. Ignoring an issue doesn't show car either. 4. The value of issues that don't have follow-ups from others affected or volunteers is low. 5. No, many stale tickets don't get re-opened. If there were more people who cared, the issue wouldn't be stale. 6. Structural changes can be found by reviewing all of open, closed and stale issues.
@joepie91 Here's example of an issue that was opened in 2018 by a co-worker and was eventually flagged by a stalebot. It's for a verifiable time zone bug. No one has fixed it since in the last seven years and no one plans to fix it now.
While it's not the resolution I wanted, the issue is indeed stale, and it's understood closing this way is more like an "archive" state than a rejection.
https://github.com/opentripplanner/OpenTripPlanner/issues/2602#issuecomment-265287233
@joepie91 @futzle If you’ve got some better ideas and some time, I’ve got some stale bug reports for you to try them out on.