Issue Tracker Comparison: Project issue tracking module vs. Google code tracker

aclight's picture

For the past two months, I have been acting as one of the administrators of the Drupal side of the Google Highly Open Participation program (GHOP for short). Briefly, this is a contest that is sponsored by Google in which secondary students (ages 13-18) can claim and complete short one week tasks created by the Drupal community for cash prizes. One of the requirements of the program is that everyone has to use the Google Code task/issue tracker for tracking the "official" progress of the students throughout their tasks. As I have been pretty involved with development of our own issue tracker (the Project issue tracking module used on, I thought it would be useful to provide a comparison of the features of these two different systems and make some suggestions of how we can improve the Project issue tracking module to make it even better than it already is.

I'll start by giving an introduction to the main issue tracking features of both the Project issue tracking module and the Google code tracker. I'll also give a description of the administrative user interface from an individual project owner/maintainer's perspective. Next, I'll provide a feature comparison and point out the pros and cons of both systems. Finally, I'll provide some recommendations on specific areas where we can add or improve the Project issue tracking module to make it better than it already is. I want to point out that I am not mentioning any of the features of either tracker that allow it to interface with code, releases, or repositories since we did not use any such features for the GHOP program and thus I would not be able to make a fair comparison.

Project issue tracking module

Basic issue tracking

To create an issue on, a user clicks the Create menu link and is taken to a form with several fields to fill out, including the Title and Body of the issue, as well as several issue metadata fields such as Project, Version, Component, Category, Priority, Assigned, and Status. At the top of the form is an area where the project's maintainer(s) can add some instructional text to remind users to search before submitting or anything else (Figure 1).
  Creating an issue
Figure 1: Creating an issue

All issues have a table displaying the current metadata values for the issue at the top (Figure 2). Notice also that issues can have links, code highlighting, and other features which are all provided by various input filters. At the bottom of each issue is the comment form where a user can update the issue or provide feedback on the issue as necessary (Figure 3).
  Issue display
Figure 2: Issue display

  Issue comment form
Figure 3: Issue comment form

The Project issue tracking module provides an overview table that displays some of the important information about many issues at once (Figure 4). The displayed issues can be filtered by the project the issue is associated with, the status of the issue, the category within the project that the issue relates to (eg. Code, Documentation, User interface), and the priority (eg. Minor, Normal, Critical). Issues of different statuses are color coded for quick identification. Issues can also be sorted by the displayed criteria by clicking the table header links.
  Issue table
Figure 4: Issue table

A link from the issues overview table takes the user to an Advanced search page, on which the user can search for issues that meet many different criteria (Figure 5). A link to the issue subscription interface is also on the overview table. Users can choose to subscribe to None, Own issues, or All issues for any particular project (Figure 6). A subscription to an issue means that the user will be notified via email whenever a new comment has been posted to a given issue, or when a new issue has been created for a given project. Own issues are issues which a given user created or has commented on. Therefore, if one wants to subscribe to an issue, he has to post a comment to the issue, even if the comment is as simple as "Subscribing".
  Advanced search
Figure 5: Advanced search

  Subscription options
Figure 6: Subscription options


Project maintainers have permission to edit their project(s), and from the edit page there is an Issues tab. The maintainer can add additional categories that will be available for users to select from and can also add text that will be displayed in a box above the submission form for all new issues (Figure 7). Finally, the project maintainer can choose to have e-mail messages sent to an address and/or have a list of all critical issues for the project sent weekly to an address.
  Project maintainer issues settings
Figure 7: Project maintainer issues settings

Project administrators (who are often also administrators of the entire site and not just one or more projects) also have the ability to create additional statuses (Figure 8). Administrators also have the ability to specify the default status (all new issues have this status, unless the submitter changes it to something else), and to specify which statuses should be included in the query that results in the default issues table discussed above.
  Project administrator statuses
Figure 8: Project administrator statuses

Google code issue tracker

Basic issue tracking

The Google code new issue form is a bit simpler than that created by the Project issues module (Figure 9), because Google stores most metadata by using Labels instead of having separate fields (I'll go into this in more depth a bit later). There is a Summary field (analogous to the "Title" field in Project issue tracking) and a Description field (same as the Body field). Once nice thing is that by default the description text area is prepopulated with a template that in many cases might lead to the user providing a more useful bug report, etc. The text of this template can be set by an administrator (see below). The owner and status metadata fields are separate fields, and then a user can add one or more labels to describe the issue. One nice feature is the yellow star, which (somewhat confusingly) means that a user is subscribed to that issue and will receive e-mail updates whenever a new comment is added to that issue. Any user can click or unclick the yellow star to toggle their subscription status to that issue.
  Create issue
Figure 9: Google tracker: Create issue

When viewing an issue that has already been created, the Google code tracker has a similar look to the Project issue tracking module with a few exceptions (Figure 10). The issue metadata is on the left and a bit more separated from the similar Project issue table, but a similar result could be accomplished via Drupal theming. More notable is the complete lack of HTML or links in the issue description. Issues all have Prev and Next links at the top which allow a user to first create a list of issues via some query and then go through them one by one. Another big difference is that, unlike with Project issues, it is not possible to edit an issue or comment using the Google code tracker. Some might argue that this is desired so that once something about an issue is created it can never change. However, the downside is that minor typos, etc. cannot be corrected easily. Just like with the Project issue tracking module, the Google code tracker highlights any changes to issue metadata made in comments.
Figure 10: Google tracker: Issue

As with the Project issue tracking module, the Google code tracker provides an overview table with listings of multiple issues at once (Figure 11). Searching for issues is very easy and fast (not surprising considering we're talking about Google). A drop down menu next to the search box allows one to search for open issue, all issues, etc. The search box allows for searching by metadata as well (eg. a search for "status:open filter" would return all open issues with the word "filter" in the body or title). An advanced search link provides an interface to restrict the search to certain words and works in a similar way to the advanced search provided by the Project issue tracking module.
  Issues table
Figure 11: Google tracker: Issues table

As I mentioned before, once nice feature of the Google code tracker is that any CamelCase label with a hyphen is interpreted as a category for the purposes of display in the issue listing table. The ClaimedBy, DueDate, and DrupalIssue columns are all generated by adding labels such as "ClaimedBy-kourge", "DueDate-2008-01-15", and "DrupalIssue-123456" to individual issues. An individual user can add one or more of these CamelCase fields to his table view by clicking on the "..." in the upper right corner of the table (Figure 12).
  View additional columns
Figure 12: Google tracker: View additional columns

At the upper right corner of the table a user can select the Grid view, which displays issues with one attribute along the X axis and one along the Y axis (Figure 13). Individual issues can be displayed by issue number (see photo) or by # of issues or title of issue. Such a view makes it easy to see at a glance how many issues with each status each user has.
  Grid view
Figure 13: Google tracker: Grid view


For users with access to administer a project's settings, it's easy to set different status values and to define which values are considered to be "Open" and which are considered to be "Closed" (Figure 14). It's also possible to predefine labels and to give each a description so that users are more likely to select the appropriate label(s) when submitting issues or comments. It is possible to specify label prefixes that can be used at most one time on any individual issue (eg. "ClaimedBy"). Finally, as mentioned above an administrator can set the default template text for issues of different types, and can also set the columns and sort order of those columns that are used in the issues table view (Figure 15).
Figure 14: Google tracker admin: Labels

Figure 15: Google tracker admin: Columns

Direct Comparison

Project issue tracking module

  • Pros
    1. Ability to edit issues and comments
    2. Input filters can be used to allow HTML code and links
    3. Good use of color in tables listing issues makes it easy to get a sense of the number of issues of various statuses (such as code needs work, review, fixed, etc.)
    4. Open source, can be modified as desired, can be run on your own site
    5. Issues and contributions across all projects by a specific user can be monitored in one place
  • Cons
    1. Adding additional types of metadata requires coding and even then is not easy
    2. Fixed issue listing table does not allow user to view additional fields
    3. Impossible to subscribe to individual issues without posting a "Subscribe" comment
    4. Impossible to unsubscribe to individual issues
    5. Free tagging of issues is not possible
    6. Some administration options (such as the possible statuses) are per-site, not per project

Google code tracker

  • Pros
    1. Search capabilities are very good and robust
    2. Additional metadata fields can be created using "CamelCasePrefix-value" labels
    3. Tables can be customized by individual users as well as project administrators to display the most useful fields
    4. Subscribing and unsubscribing to individual issues is quick and does not require creating a comment in the issue itself
    5. All configuration options are per-project, not per site
    6. Since it runs on Google's massive server farms, search and use is usually very fast
  • Cons
    1. No editing of issues or comments makes it impossible to correct typos, etc.
    2. Lack of links and code filters makes it difficult to display certain types of information, such as code, in a user friendly way
    3. Closed source and cannot be used off of
    4. No RSS feeds of issues (as far as I can tell)
    5. No cross-project tracking/monitoring of a user's individual issues/comments


From the list of pros and cons above, it's probably pretty clear that I feel that the Project issue tracking module has room for improvement. However, I do want to point out that I feel the pros of the Project issue tracking module are much more important than the pros of the Google code tracker. In my opinion, the lack of links and code styling in the Google code tracker is a significant usability hurdle. For GHOP this wasn't too big of a deal because there wasn't the need to post code in the tracker very often, but for regular development this would be a deal breaker, in my opinion.

Looking at the cons of the Project issue tracking module (and the pros of the Google code tracker), most of the items fall into three categories: viewing lists/tables of issues, subscribing/unsubscribing to issues, and categorizing/tagging issues.

Viewing lists/tables of issues

As specified in the Project* roadmap for D6, the planned conversion of the issue queues into being Views enabled (#76725)will be a big step forwards in terms of allowing for more customization of the listings. The code in the Project issue tracking module that currently handles these queries and display of the data is very much legacy code and it is extremely complicated. Offloading this onto the Views module should help to greatly simplify a key part of the module.

Subscribing to issues

The Subscriptions module has recently been rewritten and is currently in beta testing. Using the Subscriptions module (#34496) instead of the code currently built into the Project issue tracking module could be a great way to provide added subscription options while at the same time allowing us to rip a good chunk of code out of the Project issue tracking module. On a related note, the Views Bulk Operations module might provide a way to mimic the ability to subscribe/unsubscribe to an issue while viewing a list of multiple issues. [Edit: dmitrig01 has suggested that the Views Bookmarks module may be useful for this purpose as well.] [Edit again: In Drupal 6, Views Bookmarks has become the Flag module.]

Categorizing/tagging issues

I am currently working on a patch to the Project issue tracking module (#187480) that will soon allow the use of free tagging vocabularies on and on other sites using the Project issue tracking module.


While I think there are many ways in which the Project issue tracking can be improved, it is clearly a very useful tool at the moment and will only become more useful in the near future. I'd like to get feedback from others who are familiar with the Google code tracker to find out if I'm missing pros or cons of that system. Comments from GHOP students and other administrators would be especially helpful since these users have been intensely involved with both trackers recently.

Suggestions are always appreciated, but your contributions are even more valuable. You can start by reading the Project* roadmap for D6, because there's still a lot to get done there.


Excellent post, thanks!

dww's picture

Awesome write-up, aclight! This is super-useful. Nice concrete suggestions for improvement. As always, I'm incredibly grateful for (and impressed by) your efforts. comment_taxonomy_alter will be a big step forward, both for categorizing/tagging, and also making project_issue more flexible by allowing us to offload some of the existing hard-coded fields into taxonomy vocabularies.


birdmanx35's picture

Thanks very much, food for thought!

You might like to add this

Bevan's picture

You might like to add this to the d.o redesign analysis group:

Also make sure the project.module folk know about it.


Good idea

aclight's picture

That's a good idea, since any major changes to the Project issue tracking module would show up big on I've added this post to the group.

Thanks for the suggestion

Cc field

Pasqualle's picture

I am curious about the Cc field in the google tracker.
Does it mean carbon copy, like email subscription? I hope it is for user name and not a field for email address. But I do not really get it what it is good for.

Cc as in carbon copy

aclight's picture

The Cc field works like the CC (carbon copy) field for email does. We didn't really use that field much, but I believe its purpose is so that a user can subscribe someone else to an issue without that person actually logging in and subscribing themselves. As far as I know, this field requires an email address, not a Google account username. My guess is that the address is either completely hidden from other users or at least obscured like Google hides email addresses elsewhere (eg.

The actual address might be visible to project members or administrators, but I doubt it's visible to those without permissions.