issue tracking

I have read in several different discussions about the possibility of building a fairly feature-full issue tracking system with just stock cck and views. Several people have claimed to have done this, but I haven't seen any documentation, or exported views or anything like that. I think I can probably put something together, but I wanted to know if anybody has any examples or documentation available.

Thanks,
Max

A while back catch created a feature request for the Project issue tracking module to allow free tagging on issues (see http://drupal.org/node/187480). The use case he indicated was to be able to attach certain labels to issues, for example benchmark, needs re-roll, needs doxygen, etc. Other use cases would include tagging issues that need testing in certain ways (eg. MySQL, PGSQL, Javascript, IE, etc.) and tagging issues that are good for certain audiences (eg. newbie, GHOP, DROP, etc.).

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.

I've been evaluating solutions for Project management (for the duration of this post, that includes what i describe as project, issue, ticketing, case tracking, and pretty much anything that falls in that category) solutions with Drupal, over a year actually. I keep being enticed by the features of each individual solution, and new promises that are announced for each module(s) and trying them out and coming to the same conclusion with each of them. And yes, all of them seem to have the same problems that I'm hitting repeatedly.

Following a request on the dev list, an issue and first-version code has been created to return a list of current issues as a single set of data, to be downloaded and used offline.

It includes, in a single JSON object:

• the issues, selected by project, priorities, categories, and states
• the followups/comments
• the attached files

See the issue for more detail and to submit revisions.

Garrett Dimon is writing a series of posts on the design of his issue tracking system. The design if for smaller projects than Drupal, but it may provide some inspiration.

So far:

http://garrettdimon.com/archives/2007/8/14/bug_issue_tracking/
http://garrettdimon.com/archives/2007/8/20/the_tracker_status_bar/
http://garrettdimon.com/archives/2007/8/20/tracker_status_amp_comments/

As it says in the group description:

As of December 2006, there are 1500 active issues in core and almost 10000 total active issues, giving the false impression that Drupal is buggy, unreliable and unresponsive. Join the ITWG to help counteract this!

... "ITWG" being the Issue Triage Working Group (copying the IETF is lame? yes). This is not a group for the developers who squash bugs; this is a group for the obsessive-compulsive types who don't want to contribute patches, but would like to help manage the issue queue. No one seems to be doing this at the moment, but it's a job that needs doing.

Give the gift of a Drupal 5 release candidate this holiday season by fixing bugs!

The Vancouver League of Drupaliers is answering the call and organizing a Drupal 5 bug hunt!

Drupal 5 is in beta 2 and will be released when all the critical bugs are dealt with. There's also non-critical bugs and each one fixed makes Drupal 5 a better release. Your help, regardless of whether you're new or a ninja, makes the release happen at the best quality possible. (More about the ways you can help here: http://drupal.org/drupal-5.0-beta2)

What's in it for you?

Cross-posting from http://drupal.org/node/77562 ...

We've seen explosive growth in 2005 and 2006 based the ability for Drupal sites to rapidly deploy new features that meet real world customer needs, not just fulfill technical requirements. This project aims to increase consultant and site administrators ability to effectively manage releases, security, versioning, issue tracking, and feature deployment into customer ready production environments. By directly improving the Drupal.org release and project management infrastructure we will speed up the life cycle for meeting customer and user requirements and ultimately improve the ability to manage Drupal web sites. Donating to this effort (via the PayPal link on the full proposal) provides funding to accelerate volunteer contributions the Drupal.org project maintainers have made over the past 8 months.

Overview

• Contributions will have real releases and version strings, just like Drupal core itself
• Security announcements will refer to exact versions of modules that are effected
• Issues will be tracked by the exact version number of the contribution where the bug is present
• Development branches for any given version of the Drupal core -- maintainers can add new features to their module or theme without endangering the stability of other code that is compatible with the same version of Drupal core.
• All contributions will be clearly identified with the version of Drupal core they are compatible with

For the rest of the proposal, please see the full post on drupal.org.

Trac[1] and JIRA[2] seem to be likely candidates whenever software development projects need issue tracking, revision control, and wiki-esque functionality all integrated nicely. Trac is itself open source, and JIRA, while not open, is at least free for open source projects to use[3].