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