How many times have you searched for a solution to a technical issue that you are facing, only to find out that ... the issue has been CLOSED without offering any proper closure to the problem faced? Well, I have experienced it so many times, and it is all because of one pesky Github issue bot. This pesky stale bot is so annoying, that I just had to vent about it.
Why shouldn't you use a stale bot?
It is an attractive solution, after all. Implement the stale bot, close all issues that have no activity after a certain time, and voila, you magically have less issues to deal with.
But is this really the case?
New issues just pop up in its place
If you can't find an open issue for your problem, the only logical solution to the problem is to open another, right? So in effect, with a stale bot, you are encouraging duplicate issues within your issue tracker. The whole POINT of an issue tracker is to track the issues. So why substitute one issue for another issue that is just going to be merged with the first issue and then reopened and then....
Can you see where this is going? Yes, you're right -- nowhere.
Visitors coming through the search engine results get mistaken
Visitors like me, who fly through hundreds of issues each day (i exaggerate, but still, you get my point) searching for solutions to technical don't really have time to read every single discussion thread that they see. If they see that an issue is still open, it is very likely that they will take the time to scan through the entire thread to see what the problem is. But if it is closed, then visitors will likely jump to the bottom to find the solution...only to be greeted with an unhelpful stalebot message:
This just frustrates the reader and makes it even more annoying that a completely valid issue/bug was buried by a bot that thought it wasn't important just because of activity.
It gives a false sense of how well a project is managed
The holy grail of good issue tracker management: low number of issues, low number of Pull Requests. Reaching the holy grail of issue tracking by using a stale bot gives a false illusion to visitors of the project that the issues and pull requests are being resolved in a timely manner, when in effect they are just being buried and ignored by the PM/maintainers.
If you ever see a project that both uses a stale bot and has a low number of issues, don't be deceived thinking that it is a bug-free, well-run project. It is very likely that there are tons of bugs being buried alive, never to be resuscitated.
Geez, Zinc, what should we do instead?
Why not let the project manager/maintainer actually do what they're supposed to do and keep the thread alive?
Threads will only drop off for a few reasons, and for each of them, the PM/maintainer can handle them quite easily:
- It is too difficult to solve right now and everyone is clueless.
- The PM could... state that it is too difficult and ask for Pull Requests.
- There are other issues that have higher priorities.
- The PM could...mark the issue as low priority, and state a possible timeline for it to be solved.
- There are several workarounds and none of them are optimal.
- The PM could...choose a sub-optimal workaround as a temporary solution, leave the issue open with a
todolabel, and assign a priority to it
- The PM could...choose a sub-optimal workaround as a temporary solution, leave the issue open with a
- Participants do not reply
- The PM could...ping the users again to reply, before closing it for lack of information. Some participants may have found a workaround but may have not had time to post the solution. A timely reminder could benefit everyone.
- More investigation is required
- The PM could...actually do his job and investigate it.
Of course there might be a few edge cases that I have not covered, but the greatest sin of issue tracking is to bury issues unresolved. Because if you do that, then what is the point of using an issue tracker?