4 Answers
4

This depends, adding them to my own system needs to have benefit. I don't add them for the sake of having it all in my own system. How I currently approach this:

If it's a small item I have to do, I usually add it to my own system (I work on different projects with different issue trackers)

If I need to solve a bunch of issues or tasks for a specific project, I add a general GTD item in my own tracker for that project called 'Solve Issues ...'. I then use the issue tracker to view what I need to do during that time. It's pointless for me to copy all the items, when I know I need to be working on that project for a prolonged period of time.

If I'm working on a big task for a project, I tend to break it down in my own GTD system into smaller tasks.

Ultimately, you have to find a way for yourself you feel comfortable with. Your mind has to trust your system.

My understanding of GTD (and this would be an excellent time for people to correct me) is that one of the core ideas is that everything drains down into one trusted bucket of tasks - so I'd assume that under that philosophy, we'd add the tickets.

Now I don't subscribe entirely to that model (although, come to think of it I should be merging at least a couple of buckets together), and I have a separate task list for programming todos simply because it's quite quick and easy to do with eclipse. :)

I struggled with this for longer than I care to admit when I was first using GTD in a DevOps setting. In the end, I found a simple solution, but only by rethinking David Allen's GTD for this setting. He has the idea of having a "minimum number of collection buckets, and emptying them regularly". An issue tracker is something more and less than a collection bucket-- you can store great detail and context, but not necessarily a clear statement of "next action". There are likely to be multiple steps, further plans for communication, etc. Not to mention that not every action is ever going to recorded in the issue ticket itself (for reasons of tact, politics, simplification of detail, what have you). On the other hand, if you are using GTDyou want a current concise list of your next actions. What I found works for me is to view a (non-trivial) issue tracker ticket as what David Allen calls a "project". Keep your next action in your GTD system, referencing the ticket. When you complete that action, update the ticket, and create a new next action as appropriate. Sounds like more work, but I find this scales up well to an insane number of loose ends.

I think the important thing is to decide what an issue tracker actually "is" in GTD terms otherwise it can be very difficult to know where the system fits into our everyday work and weekly reviews. Is the issue tracker an "in" bucket, a "next action" list, a "project" list, or "support material"?

Items in our issue tracker are usually problems that are going to require multiple actions to solve, in GTD terms this is a "project". It can also contain detailed information about an issue which in GTD terms is "support material". The issue tracker is also a place where new work arrives either from colleagues or clients, in GTD terms an "in" bucket. However, if the issue tracker is capable of notifying of new issues by email we can disregard it as an "in" bucket because new items are included in regular email processing. Issue trackers are not suitable places to list "next actions" because they are shared and have no concept of context, so we can disregard the issue tracker for that use. So what we have left is an issue tracker that functions as a project list with attached project support material. Next actions can be determined for each "project" in the issue tracker I put these on my main "next actions" list.

In my view the projects from the issue tracker should not be copied to the main project list because that would cause unnecessary duplication of information and make reviewing difficult. I think it is acceptable to have more than one project list as long as its place in the workflow is clearly defined.