Quote Originally Posted by CoffinDodger View Post
the projects my team work on will have hundreds or thousands of "work items" and "bugs to fix" in a database, with project planning done statistically by people outside of my team, including gant charts and other planning tools. Some of these work items will be assigned to me, some I am waiting for, and a lot I don't care about.

As it's database driven, I can call up a list of items assigned to me easily, but there the similarity with GTD stops. There's not a "waiting for" list analogy in the system. Separate features of the software have their own work items within each software project, but even these can be man-months of work and a great many items.

I'm looking for a way to co-exist the two systems. How on earth do I reconcile these "super projects" with the GTD system?
Our issue tracking system sounds very similar to yours, and unfortunately, the best I've been able to do is treat it as a self-encapsulated little part of my overall GTD system.

When an issue is assigned to me, I figure out the next action and record it in the comments section right in the issue-tracking tool. The main downside to this is that I don't have a consolidated view of all my next actions for a given context: so, there are many conversations with myself like, "oh crap, why didn't I leave the query editor open so I could get info about these other 3 issues while I was in there?" Then again, I'm not that granular with my context lists.

In any event, I find it more palatable than copying much of this stuff into another set of lists.

When I assign issues to members of my team, I use the "follow issue" feature of the tracking tool instead of recording it in my @waiting list -- if I didn't do this, my @waiting list would contain a couple hundred items. This feature sends me an email any time someone updates or comments on the issue, and it is very easy for me to query the issues I am following. Maybe your tool allows for this too?