Gutenberg Contributors Consider Implementing a Bot to Close Stale Issues

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:

  1. Reduce the metric of Open Issues in github
  2. Made duplicate issues far more likely
  3. Increased friction of users reporting that the issue still exists
  4. 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.


4 responses to “Gutenberg Contributors Consider Implementing a Bot to Close Stale Issues”

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

  2. The open tickets on WordPress is a much bigger problem. There are some ancient ones about functions that are not even used anymore. It’s an on growing challenge and I think we’ll need soon a very sophisticated AI to start cleaning it up. Seriously, it’s super unfriendly.

    • We definitely need more powerful tools for issue management. I would love a way to focus efforts, for example if a release has a large set of changes around a specific feature, then be able to kick off a bot that looks at old issues around that feature and asks for confirmation. This would help reengage people on the issue, highlight changes in the product, and hopefully create a healthier repository.

      Thanks WP Tavern for highlighting the issue and discussion, it obviously is a tricky implementation to get right, which was the whole point of raising it as a post on Make.

  3. There is just too much stuff all over the place. Sometimes I do think that it’s a conspiracy of the open source. Yes, I know, it can’t be all lean, clean and streamlined like Apple. One of the downsides of democracy and open source in that matter as you end up having all this structural mess and management issues. It all starts to look messy. If it was a private company of which I was in charge I would:

    Redesign to match Gutenberg’s design.
    Streamline the navigation and thus – the functionality of it.
    Put emphasis on installing and CTA to get WP, but major focus on Blocks, Themes, Plugins.
    Dedicate a community forum which tolerates criticism.
    Streamline the blogs under one umberalla.
    Transfer dev of everything to GitHub.
    Ditch all third party offers, including the hostings – SiteGround does have vulnerability issues and is recommended.
    Hire a one-goal purpose to close tickets in order to highlight the important. When you do a spring cleanup you do it because you want to ditch the necessary and highlight the things that you have. When you have 6000+ issues and you have almost half or even more of them being already outdated, it’s hard to find the really important stuff.
    Find a more clean, minimal and streamlined way to advocate people to join in effort.

    Why do we mostly use Macs for dev work? Because it’s clean, minimal and simple. We need that hassle-free environment, the power of the identity throw branding. Clean structural changes for cognitive focus. We need that Googly type of environment where things are simple, yet deep.

    I can’t imagine how much better it would be to simplify things and close the doors of what didn’t matter and focus on what matters.

    Democracy is good, but it’s hard at fighting bureaucracy. The private sector is not democratic for a reason – in order to have efficiency and increase productivity – you have to ditch what doesn’t work, you have to willingly pull the plug on some stuff in order to focus on the other.

    Open source software development has a really hard time on streamlining stuff and cleaning things out of the way. I am not saying it’s bad and we should become Apple, but at least there should be a special position of someone who imposes his will in order to simplify stuff.

    One of the reasons why open source fails at the consumer level in many cases is exactly because of this – lack of efficiency.

    We need minimal, simplified and clean approach, clean structure which can handle the future.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: