Keeping Track

In the past year or so that I’ve been working for Mozilla I’ve found myself slowly working my way through a bunch of different ways to keep track of all of the work on my plate. I still don’t think I’ve found the best way so I wondered what other people do to manage such things?

For a rough idea of my work, most of my work is bug oriented. Either bugs that I want to work on when I get some time, bugs I am actively working on, bugs I am waiting for review on, bugs I am reviewing, bugs I am waiting to check in, bugs I want to backport to a branch… and so on. Then there is other work like planning future work and working with extension authors to help resolve their problems.

A few different approaches I’ve tried:

Bug ASSIGNED status

Simplest of all, gives me a long list of stuff I am looking at. Totally fails for prospective work though and the list gets somewhat daunting.

Status whiteboard flags

I tried for a while sticking special flags into the status whiteboard that could then be spotted in special bug queries so I could see what state each bug was in. This kind of worked, though I imagine irritated some with bugspam as I maintained the flags and a couple of times other people changed the flags.

Bugzilla tagging

Bugzilla has this tagging feature that basically lets you create named buglists. Basically like using the whiteboard stuff without having to use the whiteboard. Sadly Bugzilla’s tagging UI sucks really hard.

Bookmark tagging

With Firefox 3 I can bookmark my bugs and tag them, and use smart bookmark folders as my buglists right? Well sort of, the folder list isn’t really enough detail and there are issues with manually created smart folders that kept losing my bookmarks.

Task management software

Finally bit the bullet and stuck all of this stuff into some task managent software (Omnifocus as it happens). This is so far going ok but seems to require more dedication to keep the list up to date, I think because of having to switch to a different application so much.

So what are other people doing?

12 thoughts on “Keeping Track”

  1. At first, I splitted my my task managing into three parts:
    1. tasks with no hard dead-line which won’t be finished until tomorrow
    2. tasks with hard dead-line in a week up to the far future
    3. tasks which work during the next week

    The software I use for this:
    1. TaskCoach ( http://www.taskcoach.org/ ). I tried Omnifocus, but it took to much time to create a task and place it where I wanted.
    2. Sunbird (because of the reminder)
    3. hard-cover day planner (with a human cron job looking in the evening what I got done and what I have to reschedule)

  2. I use status whiteboard for bugs, and when I have to talk to someone about a bug, I use the quick shortcut key to enter a task into Omnifocus (ctrl + option + space).

  3. A combination of voting, CC’ing, watching QA, and assigning bug. A saved search looking for bugs I’m CC’d to as well helps here.

  4. I use a combination:
    Status Whiteboard (I use the whiteboard to say when a bug is finished but not available for qa testing yet)
    Status (bugs are unconfirmed until they are put on a backlog or a release, then are new until I have started on them, some never get to assigned if I finish them with a single commit)
    Priority (I work on items from P1 first down to P5 last)
    Deadline (items with a hard deadline known have it set)
    Dependency/Blocks (all items block a backlog or a named release)

  6. Archaeopteryx: Keeping tasks in 3 different places just seems like a recipe for disaster to me, I would inevitably get confused over where each task would meant to be (which in your definitions changes from week to week) and probably just not maintain them.

    Joshua: Watching the QA only really keeps me informed of new tasks and that works fine. I use CC’ing for all bugs that I am interested in, which means the list is so large I can only look at it to find a bug I know is already there. And assigning as I said makes the list too long to be manageable, and that’s even with not assigning bugs that I haven’t started working on yet.

    Bill: All those are useful, though it is unfortunate that the deadline and priority tend to get used for the driver’s purposes than the bug assignee’s.

    Rohan: Doesn’t seem to provide anything above Omnifocus and I find web-based tools like that very un-user-friendly.

  8. What I do is simply have all my bugmail in Thunderbird, and create saved search folders for each “task”.

    I then whenever I CC myself, on a bug, or am waiting on a review, will edit my filter for “Subject contains” and do a “[Bug 123456]” entry. So that I have the entire bugmail for each of those bugs in the folder, especially as it comes in (in the case of pending reviews).

    It works out quite well in the times I remember to update it.

  9. I started off keeping tabs open for bugs I was following/working on. This quickly bogged down the browser and after 250 tabs I gave up. I switched to flagging bugmail that I was interested in. When that backlogged to 150 I decided to look through and see what still needed follow up and out of the 60 or so old bugs I’ve looked at about a third of them had already been followed up (whether by me or by someone else). Callek’s idea of search folders looks interesting, maybe I should give it a go.

  11. Pingback: Oxymoronical » Blog Archive » I must be missing something in the clouds

  12. It seems like Deskzilla (http://almworks.com/deskzilla) can help a lot to do all the tracking. First of all, it’s a desktop application designed to work with Bugzilla automatically — no need to manually put the data anywhere, it tracks changes on the web and makes your changes into Bugzilla.
    Tagging can be done either with Bugzilla keywords (with much nicer UI than on the web) or with local tags — they are not seen from Bugzilla, and the process of managing them doesn’t send lots of email annoying other people. There’s a nice tool to create any boolean search and store all searches in a hierarchical tree-like view.

Comments are closed.