Fine-grained permissions for Github issues (self-assign, labels)

One way to lighten some of the bookkeeping tasks for contributors would be to allow anyone opening an issue to label it appropriately (for instance, I had to request that have the "needs discussion" label). Committers can always revise these, but in most cases an issue writer will probably know at least some of the labels that are appropriate.

It would also be nice if any user could self-assign or deassign themselves from an issue, so that "in progress" labels might no longer be necessary.

Does anyone know of a way to allow non-committers to do this in github? @LN mentioned that achieves the features I'm looking for, but doesn't integrate with slack. Unless I hear back, I'll start poking around to see if I can find and propose a solution here.


This is a big pain point, thanks for bringing it up here and in Slack, @daveycrockett!! It would be amazing for any contributor to be able to claim and tag issues and make the state of each issue and pull request so much clearer.

I don't think a GitHub bot needs to integrate with chat at all. I was just reading through the zulipbot installation docs I'm not seeing immediate evidence that zulipbot does integrate with Zulip, do you have pointers to that integration and what it might be for?

Right you are! That's what I get for confusing "made BY zulip" with "made FOR zulip" :slight_smile:

So if this install doc is correct, it seems pretty straightforward. I don't like having to store passwords in plaintext, but if it's running on a hardened server that may be acceptable?

Is there a place this could live (related to, and if I can get access, is there interest in me spinning an instance of the bot up?

1 Like

Ahh, yes. I threw that out there without much context. My understanding is that it only interfaces with GitHub.

I saw other projects that use similar bots such as Kubernetes but none that seemed as easy to configure for new environments as zulipbot. Might be worth doing a quick sanity check to make sure I didn't miss anything.

For credentials, I wonder if there's a way to have it read from environment variables?

Seems the server that runs Slack would be a good one to use. @yanokwa is probably the only person who has the keys to that castle currently so he will need to follow up (we should fix that too, thanks for bringing it up).

I haven't tried any of them, but I think Hubot (which works with Slack) has several different choices of scripts that may cover all you need, including:

That said I'm a huge fan of Zulip (free hosting for open source!) and using open source software when possible, so I'll still give a +1 there too. :slight_smile:

I agree that this is a problem and Zulipbot has come up as a solution, so let's try it! And unless there is a good reason for installing this on a machine where we have to maintain it (e.g., AWS/DO), we should go with Heroku.

@daveycrockett can you try to install Zulipbot on your own Heroku account and share the high-level instructions here? I'm also interested in how updates happen on Heroku.

Anyway, once we have your instructions, it'll easy for me to set it up on ODK's Heroku account and unleash @opendatakit-bot to help manage our issues.

1 Like

I've successfully installed zulipbot on heroku using the instructions for heroku and zulipbot, and I've included a step-by-step playbook below. Examples in action for an organizational repo are here and personal repo are here (thanks for helping me test @LN and @downey)!

Two issues:

  1. Permissions - you have to be a member of a team that has at least 'read' access to a project (or be a collaborator, in the case of a personal project) in order to @bot properly.
  2. Documentation - the above permission problem may be something that's configurable, but the config docs for zulip bot are a little sparse.
  3. Security - I'm not a heroku expert, but I'm told editing files directly using 'heroku bash' on your instance doesn't guarantee persistence, and that pushing to the heroku remote is the way to ensure that. Adding my password and secret to get the webhooks to work required committing passwords in cleartext to the repo, and pushing to remote (see playbook below). Hoping someone more knowledgable of heroku than I am can comment on this.

Otherwise, it works as advertised, team members can assign and label and do other things without being admins!


  1. install npm/node and git
  2. download heroku CLI:
  3. heroku login
  4. git clone
  5. cd zulipbot
  6. npm install
  7. heroku create
  8. git remote -v verify a new remote has been established, called "heroku",
  9. create a github account for the odk-zulipbot, and add it as a collaborator (and admin) to the appropriate repos
  10. add webhooks to the appropriate repos
  • uri:
  • application/json data
  • secret: <generated, to be used below>
  • send me everything
  1. cp src/zulip_project_config.js src/config.js # copy the example template into where the live config lives
  2. touch src/secrets.json
  3. In config.js, I only changed sudoUsers (no idea what this does) and activeRepos, none of this is documented so I don't know what the other parameters do :confused:
  4. add secrets content as directed (github account credentials, plus the webhook secret generated above)
  5. I then removed secrets.json and config.js from .gitignore, git add -A, git commit, git push heroku master. This seems like a bad idea.

Thanks, @daveycrockett, this is awesome! @yanokwa asked for some documentation on the project's GitHub and the answer was insightful - I'm following to see what else they add.

I do hope someone has suggestions regarding passwords.

1 Like

Pleased to announce that zulipbot is now deployed on the following repos:

  • opendatakit/aggregate
  • opendatakit/briefcase
  • opendatakit/build
  • opendatakit/collect
  • opendatakit/docs
  • opendatakit/javarosa
  • opendatakit/xforms-spec

It's pretty easy to use.

  • Claim/unclaim an issue — Comment @opendatakit-bot claim on the issue you want to claim; @opendatakit-bot will assign you to the issue and label the issue as in progress. If you didn't want to work on the issue anymore, comment @opendatakit-bot unclaim to unclaim it.

  • Label/unlabel issues — You can label issues by including @opendatakit-bot label in an issue comment or the body of your issue followed by the desired labels enclosed within double quotes (@opendatakit-bot label "bug" "high priority"). You can remove labels by commenting @opendatakit-bot unlabel followed by the desired labels enclosed with double quotes.

  • Workflow automation@opendatakit-bot will watch all claimed issues. If there is no activity in 7 days, the claimer will be reminded to update issue. If there is no response for 3 days, the issue will be unclaimed.

I'll put a summary of this in our contribution guides, and we'll see how it works out. Thanks @daveycrockett for your help in making this happen!


Hooray! This is awesome.

1 Like