logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

stalebot.md (3245B)

    

  1. ---
  2. title: GitHub stale bot considered harmful
  3. date: 2021-10-26
  4. ---
  6. Disclaimer: I work for a GitHub competitor.
  8. One of GitHub's "recommended" marketplace features is the "stale" bot. The
  9. purpose of this bot is to automatically close GitHub issues after a period of
  10. inactivity, 60 days by default. You have probably encountered it yourself in the
  11. course of your work.
  13. This is a terrible, horrible, no good, very bad idea.
  15. ![A screenshot of an interaction with this bot](https://l.sr.ht/nNyI.png)
  17. I'm not sure what motivates maintainers to install this on their repository,
  18. other than the fact that GitHub recommends it to them. Perhaps it's motivated by
  19. a feeling of shame for having a lot of unanswered issues? If so, this might stem
  20. from a misunderstanding of the responsibilities a maintainer has to their
  21. project. You are not obligated to respond to every issue, implement every
  22. feature request, or fix every bug, or even acknowledge them in any way.
  24. Let me offer you a different way of thinking about issues: a place for motivated
  25. users to collaborate on narrowing down the problem and planning a potential fix.
  26. A space for the community to work, rather than an action item for you to deal
  27. with personally. It gives people a place to record additional information, and,
  28. ultimately, put together a pull request for you to review. It does not matter if
  29. this process takes days or weeks or years to complete. Over time, the issue will
  30. accumulate details and workarounds to help users identify and diagnose the
  31. problem, and to provide information for the person that might eventually write a
  32. patch/pull request.
  34. It's entirely valid to just ignore your bug tracker entirely and leave it up to
  35. users to deal with themselves. There is no shame in having a lot of open issues
  36. — if anything, it signals popularity. Don't deny your users access to an
  37. important mutual support resource, and a crucial funnel to bring new
  38. contributors into your project.
  40. This is the approach I would recommend on GitHub, but for illustrative purposes
  41. I'll also explain a slightly modified approach I encourage for SourceHut users.
  42. sr.ht provides mailing lists (and, soon, IRC chat rooms), which are recommended
  43. for first-line support and discussion about your project, including bug reports,
  44. troubleshooting, and feature requests, instead of filing a ticket (our name for
  45. issues). The mailing list gives you a space to refine the bug report, solicit
  46. extra details or point out an existing ticket, or clarifying and narrowing down
  47. feature requests. This significantly improves the quality of bug reports,
  48. eliminates duplicates, and better leverages the community for support, resulting
  49. in every single ticket representing a unique, actionable item.
  51. I will eventually ask the user to file a ticket when the bug or feature request
  52. is confirmed. This does not imply that I will follow up with a fix or
  53. implementation on any particular time frame. It just provides this space I
  54. discussed before: somewhere to collect more details, workarounds, and additional
  55. information for users who experience a bug or want a feature, and to plan for
  56. its eventual implementation at an undefined point in the future, either from a
  57. SourceHut maintainer or from the community.