Please Stop Using the Stale Bot Incorrectly

!
Warning: This post is over 365 days old. The information may be out of date.

A lot of projects on GitHub use the “GitHub Stale Bot” to automatically close issues (and pull requests) that have not been updated in a while. The bot automatically goes through the issues and leaves a comment asking if the issue is still relevant, then auto-closes the issue if no comment reply is left within a certain time period configured by the repository owner.

This is absolutely terrible, both for the user and also the developer.

Old issues are buried

Issues are not out of sight, out of mind – even if you close them off with the stale bot that doesn’t mean your project has one less bug.

In fact, it’s even worse for your project, because now all of the relevant information regarding the bug has been buried into the “Closed” section of GitHub issues. People can’t find the existing issue, so what do they do? Create a new issue. Which means you need to:

a) mark the new issue as a duplicate and re-open the old one, or

b) find some way of merging the issue chains, or

c) upset your users by having them copy and paste all the relevant information from the old issue

Which leads to…

More work

Rather than reducing the burden of the developers, the stale bot ironically creates even more administrative work down the line as issues are buried and duplicate ones are newly filed, doing the polar opposite of what the bot originally set out to achieve. So instead of spending your time writing code, you need to babysit the bot and deal with the backlash when it inevitably pisses off the users of your project.

Messy threads

So let’s say users of your project are active and can reply to the bot, indicating that a given issue is still relevant. However, as long as the bot stays active, the back and forth like the following will continue:

GSB (GitHub Stale Bot): Hey, this issue seems inactive. Close it?

GSB added the stale tag.

User: No, it’s still relevant.

GSB removed the stale tag.

(a few moments later)

GSB: Hey, this issue seems inactive. Close it?

GSB added the stale tag.

User: No… it’s still relevant.

GSB removed the stale tag.

Developer: I’m still working on the fix, but we’re blocked on dependency X at the moment.

GSB: Hey, this issue seems inactive. Close it?

GSB added the stale tag.

Developer: kill me

GSB removed the stale tag.

Same conversation, without the annoying bot:

Developer: I’m still working on the fix, but we’re blocked on dependency X at the moment.

(a few moments later)

Developer: Okay, upstream fixed their stuff, now we can finally create a patch!

Developer merged feature-fix branch.

Developer closed as completed.

I know which thread I prefer, both as a developer and as a user.

But…

Okay, I’ll admit there is one use for the Stale Bot. And that is when you’re awaiting user feedback.

If the user doesn’t reply in X amount of time (X here depends on your patience), it’s totally fine for the stale bot to drop the issue, because in my opinion it usually means the issue wasn’t that important to them and therefore they didn’t bother with following up with further information, like debugging logs and such.

So have the bot only monitor issues with a specific tag, like awaiting-user-feedback, and start the countdown once the tag has been added to an issue.

This is honestly the only valid use case I found for the Stale Bot, that actually relieves some of the hassle of dealing with “stale” bug reports.

Conclusion

Just because a given issue doesn’t have a reply for a while doesn’t mean it’s stale! Please stop using the stale bot incorrectly. Your project users (and developers) will thank you. :)

comments