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 drupal.org), 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.
Basic issue tracking
To create an issue on drupal.org, 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).
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).
Figure 2: Issue display
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.
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".
Figure 5: Advanced search
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.
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.
Figure 8: Project administrator statuses
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.
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.
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).
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.
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
Project issue tracking module
- Ability to edit issues and comments
- Input filters can be used to allow HTML code and links
- 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.)
- Open source, can be modified as desired, can be run on your own site
- Issues and contributions across all projects by a specific user can be monitored in one place
- Adding additional types of metadata requires coding and even then is not easy
- Fixed issue listing table does not allow user to view additional fields
- Impossible to subscribe to individual issues without posting a "Subscribe" comment
- Impossible to unsubscribe to individual issues
- Free tagging of issues is not possible
- Some administration options (such as the possible statuses) are per-site, not per project
Google code tracker
- Search capabilities are very good and robust
- Additional metadata fields can be created using "CamelCasePrefix-value" labels
- Tables can be customized by individual users as well as project administrators to display the most useful fields
- Subscribing and unsubscribing to individual issues is quick and does not require creating a comment in the issue itself
- All configuration options are per-project, not per site
- Since it runs on Google's massive server farms, search and use is usually very fast
- No editing of issues or comments makes it impossible to correct typos, etc.
- Lack of links and code filters makes it difficult to display certain types of information, such as code, in a user friendly way
- Closed source and cannot be used off of code.google.com
- No RSS feeds of issues (as far as I can tell)
- 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.]
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 drupal.org 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.