Skip to content

Instantly share code, notes, and snippets.

@micimize
Last active May 5, 2020 14:06
Show Gist options
  • Save micimize/416268ae7f45aabb4da79654f8b89c03 to your computer and use it in GitHub Desktop.
Save micimize/416268ae7f45aabb4da79654f8b89c03 to your computer and use it in GitHub Desktop.

Loose Lockbot Thoughts

Closed issue threads, even very old ones, have a great deal of utility to project communities. They are a common place for users to share workarounds, caveats, and link to related issues.

Instead of simply locking a thread, if we could:

  • automatically unsubscribe maintainers (and comment "tag {maintainer} if and only if this is still an issue")
  • comment and label the issue accordingly
  • have a user-level bot for opt-in "soft-lock" notification unsubscriptions.

In the real world, superset manages without locks and has a .pinned tag to prevent automatic closure. The flutter maintainers somehow go without any close bot at all.

Speaking personally, there is probably no OS-related experience more frustrating than finding an X-years old issue for my exact problem that was automatically closed and locked by bots. We need a more nuanced solution to the problem of maintainer notification overload.


Locked threads are much more than a "minor inconvenience" to users. Commenting "still broken on v2" on a closed issue is a much lower activation cost than a new issue, And it makes the issue more glanceable because context can be consolidated.

As a maintainer myself, I empathize with how valuable the notification noise reduction is. But, the result here is that if a user has something to contribute that isn't worth a new issue, that contribution is not made, or else the maintainers get even more noise because that user has to open a new issue or w/e (where the other community members who had the same issue are no longer in-thread to help).


One of the major reasons I stopped using react native was because (at the time) so many issues were auto stale => locked.

Let's take as an example, this issue that is nothing but users troubleshooting. The current possible states of the underlying issue are:

  • It was resolved with no other issue created. That knowledge will likely never be recorded.
  • A new issue was created and resolved. If that issue was then locked, the knowledge that they are related will likely never be recorded (beyond implicitly by the right keyword search)
  • It was never resolved. Eventually a new user encounters the same issue and opens it anew, possibly linking it. All the old context is lost until possibly excavated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment