FAQ
zulipbot is a GitHub workflow bot software written in Node.js that manages issues and pull requests in the repository in order to create a better workflow for contributors. The code is open source, actively developed, and designed to be fully configurable so that multiple projects can benefit from it.
zulipbot was originally developed for the Zulip organization, developers of the powerful, open source group chat application of the same name. With one of the largest active development community among the modern open source group chat tools, Zulip faced major productivity problems for the project, caused by longstanding limitations in GitHub’s permissions and notifications systems.
Rather than waiting for GitHub to solve these problems, Zulip developers created zulipbot to patch these limitations in GitHub’s model, creating a significantly more democratic workflow for Zulip contributors, allowing them to claim issues, manage labels, and transition from new contributors to being the maintainer of their portion of the busy Zulip server project, even if they’re a volunteer with only a bit of free time. Ever since it was first deployed on Zulip repositories on February 12, 2017, zulipbot has become a beloved member of the Zulip development community.
Some of the GitHub limitations that zulipbot rectifies include:
- Notifications: GitHub’s notification system has no direct support for subscribing to a subset of the issues/PRs in a repository; so you either get only the issues you’ve participated on or the entire firehose (which for Zulip is usually more than 100 emails per day). The practical effect for us was that it was very expensive for a contributor to start managing the issues in just one part of Zulip without a ton of overhead. Before zulipbot, the core developers doing issue triage had to spend a lot of time to mentioning individuals just to make sure they knew about new issues or PRs in their area, which was incredibly painful.
- Issue assignment: GitHub’s issue tracker only allows users with full write access to a repository to assign issues (even to themselves, aka claiming an issue to work on). This means that in order to have GitHub keep track of which issues are being worked on, we need to either give every one of our hundreds of contributors full write access to the repository (which is asking for a bunch of accidental pushes).
- Abandoning issues: GitHub doesn’t even let a contributor without full write access abandon an issue they’ve been assigned.
- Abandoned claimed issues: Zulip had a big problem with people posting on a issue that they were going to work on it, and then never being seen again. This slows down the project, since other contributors would generally not try to fix those issues, even if it’s kinda clear that the person wasn’t working on it (e.g. it was a small bug and had been 3 months).
- Issue triage: GitHub’s issue tracker only allows users with full write access to a repository to label issues. As a result, new issue triage was limited to the project’s very busy committers. We really wanted to be able to spread the workload among a wider section of our community, including members who might be great at issue triage but don’t have the experience with either the project or Git to be ready for full write access.
Unfortunately, we do not. We recommend using Heroku or Amazon Web Services (AWS) for hosting your copy of zulipbot, since both services offer free plans to their consumers.
You can create an issue in the zulipbot issue tracker or visit us on the zulipbot stream on the Zulip development community server for help and feedback on your issues.
Need more help? Join us on the zulipbot stream on the Zulip development community server.
