Using the GitHub Issue Tracker for Large Projects

Within the last year, our engineering team transitioned from using Redmine for all of our issue tracking to using the GitHub Issue Tracking system. We had previously moved all of our repository hosting to GitHub, so the transition made sense; it gives us an easy way to link commits, source code, and bug reports together.

Our software driver, UHD, is a pretty large project. Not only is it just a lot of "Lines of Code", but the nature of the code is very diverse. It includes C++ host code, embedded C code, Verilog for FPGAs, 8051 code for microcontrollers, etc., We need a pretty complete issue tracking system to keep a handle on everything.

After a few months of using the GitHub issue tracker, I'm comfortable saying that it serves the purpose, but it could definitely use some improvements.

Here are my primary issues with the issue tracker:


The GitHub tracker does everything in terms of 'labels' - very similar to how GMail handles things. Each bug can be assigned any number of labels, and can be assigned to one milestone. If you want to filter the bugs you are looking at, you can filter by labels and milestones.

Applied Filters

Fundamentally, I like the "label" idea. It works great in GMail, and there isn't a reason it can't also be great in GitHub. Unfortunately, the UI for interacting with the bugs makes it impossible to tell when a filter (i.e., you have selected labels to filter by) is applied.

As an example, check out this picture. This is what the issue tracker looks like without any filters applied:


...and this is what it looks like with a label applied:


Can you see a difference? If I hadn't of told you that the second image was filtering by a selection of labels, would you have known? Even if you know a filter is applied, how can you tell what the filter is (I didn't black out anything that would have covered it up).

It is, indeed, not very intuitive, and can be very confusing.

Applying Filters

We have 40+ labels that we use to classify and identify bugs at various points of the workflow. The only interface for applying labels as filters to look at bugs, though, is to look at a list of the labels on the side of screen. With a bunch of labels, you have to scroll a good ways to find the labels you are looking for, which once again means you can't actually see the labels you have already applied.

Filtering by Assignee

A very important feature that is missing, I think, is filtering the bugs by assignee. There is an obvious way to filter the bugs "Assigned to You" and "Created by You", but there actually isn't a way to look at bugs assigned to anyone else.

You can pull this off by manually manipulating the URL string if you know someone's exact username, but there is obviously a gap in the interface if you have to resort to that sort of URL hacking.


The GitHub Issue Tracker doesn't naturally enable, or enforce, any particular workflow. As a result, you are left to implement you own using the labeling system. We use a pretty typical workflow (new --> triaged --> working --> review --> close) - but we have to implement this workflow manually with labels.

It gets the job done, but it's a bit clunky, and the platform doesn't actually provide any enforcement of the workflow. This is fine for a relatively small team where the workflow can be enforced as part of the group dynamic, but it may be hard to manage with larger organizations.

Multi-Repository Set-ups

We use a number of different repositories for our development. GitHub associates issue trackers with specific repositories, which Redmine does as well, but a crucial difference is that Redmine lets you view & manipulate issues from all of your trackers (i.e., repos) from one place. GitHub doesn't provide this.

As a result, you have the option of either keeping all of your issues on one tracker associated with one repository, regardless of whether the code is actually in that repository, or trying to manage one issue tracker for each separate repository, despite the fact that they are all associated with the same project.


Overall, I love using GitHub, and the Issue Tracker is fulfilling our needs after forcing our workflow onto the labeling system. The interface is just a bit... klunky. It is obviously geared for stand-alone repositories that are contained projects. I'm hopeful that GitHub continues to improve the interface and feature set.

Ben Hilburn

Ben Hilburn

bits, nibbles, bytes, and words
D.C. Metro Area