Gutenberg project contributors are considering implementing a stale bot to tame the repository’s overgrown issues queue, which currently has 2,733 open issues. Stale bots are usually employed to automatically close “stale” issues and PRs based on a predefined set of parameters for inactivity.
“The current recommendation is to set our policy to a 180-day of no activity, so if no comments or commits are on an issue or PR in 180 days, then the bot will post a comment to the issue alerting the user it will be closed in 7-days due to inactivity,” Marcus Kazmierczak proposed.
One important concern is getting the tone right for the automatically-generated message. When you’re employing bots on a widely used open source project, they had better be friendly. A chilly, indifferent bot can unwittingly turn away potential contributors with the wrong kind of messaging. Kazmierczak proposed the following message:
This is an auto-generated message to let you know that this issue has gone 180 days without any activity and meets the project’s definition of stale. This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a “bump” to keep it open, or add the “[Status] Not Stale” label. Thanks for keeping our repository healthy!
Participants in the discussion on the proposal are divided on the best approach. Daniel Llewellyn, one of the most vocal opponents to using a stale bot, contends that an automatically closing issues sends the wrong message.
“If we care about users and that they trust that we will fix their problem then automatically closing their issue gives them the signal that we don’t,” Llewellyn said.
“If you don’t want to fix a problem then it is better for a human to explain why the problem won’t be fixed and personally close the issue. Automating this on the assumption that because nobody has commented in a while means it isn’t important is bad!”
Joy Reynolds agreed with this assessment, noting that closing issues through any means can be discouraging.
“I’ve had issues closed by humans for being stale, also, and it isn’t any better,” Reynolds said. “I’ve had issues closed because someone created a new issue on the same thing. This loses all the history and the watchers.
“I’ve also had an issue closed at Launchpad for being stale (and their system used only two weeks as a time frame). That served no purpose at all. It only makes people go away, frustrated.”
Kazmierczak reiterated in the comments that the bot can be configured to skip issues labeled as bugs and that issues and PRs can be bumped to reset the 6-month clock.
“The overall goal of the proposal is to improve feedback and responses to issues by ensuring what’s there is relevant,” Kazmierczak said.
Auto-closing issues is the most controversial part of the plan. The general consensus in the comments leans towards using the bot for labeling and triaging in order to manually close the issue later.
“My preference would be for a bot to alert humans in a slack channel when a ticket is declared stale and become progressively more insistent until a human responds,” Peter Wilson said.
Milana Cap suggested using a bot to nudge the ticket author as a compromise between “being friendly and thoughtful to contributors while keeping maintainers sane.”
Whatever approach contributors land on, excluding tickets marked as bugs is going to be critical for making the stale bot productive. Otherwise, it becomes just a fancy way of kicking the can down the road, delaying the inevitable.
In a recent post titled “Github Stale Bots: A False Economy,” software developer Ben Winding wrote about why stale bots don’t deliver what maintainers are aiming to achieve. Based on his experience with the Angular repository’s bot, Winding summarized the stale bot’s effect on the issues queue:
- Reduce the metric of Open Issues in github
- Made duplicate issues far more likely
- Increased friction of users reporting that the issue still exists
- Ultimately decreased the quality of the software, as the issues don’t accurately reflect reality
If the Gutenberg repository’s stale bot can be configured not to close bugs and used to maximize human involvement, it will be less likely to deter people from reporting issues. Feedback on the proposal is open until January 29, 2021. Kazmierczak is seeking input on the bot’s implementation, specifically its time threshold and messaging.
Well blow me down with a pocket fan.. I’ve made it onto the Tavern. There’s nothing I can’t do now!
Seriously, though, thanks for the support – this is a topic I passionately believe in and want the world to understand. Well done for finding Ben Winding’s analysis that supports my stance, that helps to convey the problems that a stale bot introduces with little if any benefit.