Indistinguishable from Jesse

I often come across a bug report and decide that I want to do something once it's fixed:

• Once bug X is fixed, tweet joyfully.
• Once bug X is fixed, update some documentation.
• Once bug X is fixed, add a feature to a fuzzer.
• Once bug X is fixed, retest a fuzz testcase that I assumed triggered bug X but might in fact trigger a different bug.
• Once bug X is fixed, add a regression test for bug W.
• Once bug X is fixed, see if it also fixed bug Y.

I could CC myself to the bug, but then I'll get lots of email and might forget my reason for being CCed. I could create a dependency, but that sends everyone else confusing bugspam and gives me notifications that are easy to miss.

The after-fix tool

I created a tool called after-fix to track these bug-dependent tasks for me. I have a large after-fix config file with entries like:

# Make use of new GC APIs in DOM fuzzer bug 661469

I'll see my note the next time I run after-fix after bug 661469 is fixed.

Pruning workarounds

I've also been using after-fix to ensure workarounds don't outlive their purpose:

• Prune fuzz ignore lists as the relevant bugs are fixed.
• Find obsolete skips and fails in Firefox's regression-test manifests.

Getting Things Done recommends spending an hour or two on a "weekly review" every Friday afternoon. This worked for me at first, but after a month, I found myself procrastinating more often than actually doing a weekly review. Ironically, another concept from the same book helped me understand some of the reasons.

A major problem with my old weekly review checklist was that it included things I had to do in different contexts. For example, I can only check snail mail at home, but I can only check voice mail when I'm not at home. Worse, performing a weekly review seemed to require concentrating on one thing for an hour, and I'd rather spend that concentration on programming.

I decided to split my weekly review into a list of weekly sanity reminders, with each reminder on appropriate day of the week. I chose Monday for reviewing actions assigned to specific contexts, since the contexts "office" and "business-hours" usually become available on Monday. But I review coding projects later in the week, when distractions have died down.

For many of the smaller parts of my old weekly review, such as making sure my iPhone's voicemail list is empty, I chose a day of the week on which a mid-day meeting breaks up my day.

Splitting my weekly review into multiple scheduled items allowed me to put some reminders on the days when they do the most good, and others on the days when distractions do the least harm.

Like the author of GTD, I found that doing each of these things once a week helps me focus on the right projects and avoid some forms of procrastination. They just don't all need to be done on the same day.

Dave Cronin complains that when he misses a call and gets voicemail as a result, the iPhone forces him to click both Recents and Voicemail to clear badges.

I agree with his complaint, but I don't like his proposed solution of making call history and voicemail a single list. I worry that with his design, leaving voicemails for an iPhone user would become a crapshoot, similar to emailing many people.

The reason email works poorly for many people is that it encourages them to mix reference information with to-do-reminders. A reminder mixed with a large amount of reference information is as good as forgotten. Good default workflow is especially important for voicemail, given its status as the last bastion of sanity in many lives:

I have never heard anybody say, “I get too many messages on my answering machine. I get too many voicemails.” What’s the difference? There’s no difference. [Just like with email], you get stuff that’s just reference stuff, that’s just trash, and stuff you need to act on.

What people don’t do is leave it there, undecided. But they do about e-mail. They also do it by paper. That’s why most people are highly voice-addicted, and most cultures are voice-addicted. That’s why interruptitis is so huge out there, because if you have something you consider timely and meaningful that somebody needs to know and hear, you’ve got to deliver it to them by some sort of auditory means, because that’s the only thing they’re processing.

Well, I just go, “Duh! Somebody give me the rationale for this.” And there is none. E-mail wouldn’t be a problem if it blew up like your answering machine did once you got more than a screen full.

The iPhone Recents list is primarily reference information. In particular, it provides shortcuts for calling people you have talked with recently. Mixing voicemail with Recents would force you to mix reference and reminders, because unlike with email, you have no other good place to put the reference information.

How could Apple address Cronin's complaint without leading iPhone voicemail users into the same trap that email leads people into? I think the solution is to divide the list not by kind (calls vs voicemails) but by purpose (needs-processing vs reference). An "In" list would show both voicemails and missed calls, and encourage you to keep it empty. The "Recents" list would serve only as reference; you would never feel compelled to go there to change something.

One challenge with my design is to ensure that removing missed calls from "In" feels more natural than ignoring them. Otherwise, users will fall into the email-like trap, just like I fear they would with Cronin's design. I suspect it would be best if it feels like moving the missed calls to Recents, rather than deleting them. A "Clear Missed" button button might also help.

Last night I posted a new guide to triaging crash bugs.

Reports of crash bugs require a variety of skills to turn into useful bugs: knowing common support issues, tactfully interacting with bug reporters, reducing testcases, finding regression ranges, and knowing how to get each bug to the correct developer(s). I don't expect every triager to be a guru at all of these, so my guide incorporates a workflow that should allow triagers with differing skills to work together efficiently.

I'm going to work with the QA team to organize some "crash bug days" on IRC, but I'm interested in feedback before that as well.

I'd like to see more software nudge people in the direction of GTD's low-stress productivity.

Quests

World of Warcraft organizes your quests according to where you discovered them, not according to where you can make progress on them. You can easily have your character in the right town but forget to advance one of your quests.

Since the game's quest organization is so unwieldy, it limits players to 25 quests. This forces some players to abandon quests with the intent of picking them up again later. But more importantly, "only write down the most important stuff" is the wrong message to send to our children.

Having to maintain your own lists outside of the game makes playing the game too much like work. If instead, the game subtly taught players how to work effectively, they might have more time to play.

Mail

Thunderbird's default set of color labels reflects priorities and reasons (important, work, personal, to do, later). These labels don't really help move messages out of the inbox.

Instead, Thunderbird should suggest contexts and non-action sets (home, office, errands, waiting for reply, reference).

Bookmarks

Firefox has the distinction of containing three dangerous stuff magnets: the bookmarks menu, the bookmarks toolbar, and session restore. I've seen several coworkers fall into the session restore trap, and it's not pretty: with hundreds of tabs, Firefox can take minutes to start.

I like Jono's suggestion of replacing bookmarks with features that speak more directly to use cases like to-read, sharing, and reference. Firefox 3's tags make reference possible but not much else.

To-read is the trickiest, since it can't really be organized. Separating to-read from sharing and reference is enough to keep those other categories clean, but to-read has to work if it's going to be used. Maybe Firefox can include hints about how to use to-read effectively, like having an "airplane" button you click to open all of them in tabs just before you disconnect from the tubes. Or maybe Firefox can keep those items ready for reading without the overhead of having them open in tabs all the time.

Everywhere

What other software could encourage people to discover contexts and the next-action principle? Where else can workflows be improved, so collection buckets are emptied naturally, and users don't need to make a special effort to "stay organized"?

I believe Bugzilla's workflow can be improved using one of the central ideas from Getting Things Done, the "next action".

Currently, the answer to the question "what is needed to move this bug forward?" is scattered throughout each bug report. Sometimes it's a keyword, sometimes it's a review flag, and sometimes it's the third-to-last comment. It takes me maybe a minute per bug to determine whether I can help, and this wasted time adds up quickly.

Next-actions for bugs

I propose replacing the status field with a next action field, and the assignee field with a next action assignee field. The "next action" field answers the question "what is needed to move this bug forward":

Organizing actions by context lets me remember projects when I can move them forward, rather than when they only increase my anxiety. This may be even more important in a community system: who you are is a key context determining whether you can do something.

With a next-action field, it would be easier to find places to put my skills to good use:

• Did Brendan hope to have this patch fuzzed?
• What bugs are waiting for input from the security team?
• What bugs could benefit from extension-space experimentation?

With the addition of a next-action-assignee field, I'd also be able to do searches like:

• What have I been asked to do in Bugzilla?
• What blockers are stuck on me?
• What bugs need someone to volunteer to make a reduced testcase?

Simplifying Bugzilla

I'm asking for new fields, but I think this will actually make Bugzilla less complicated. The "next action" field and its assignee would replace:

• The current "status" field, which is mostly useless because each open state (unconfirmed / new / reopened / assigned) can mean so many different things.
• The current "assignee" field, which is misleading when the next action required is anything other than "write a patch" or "check it in".
• Eleven keywords: uiwanted, qawanted, helpwanted, stackwanted, icon, testtracker, crashreportid, regressionwindow-wanted, testcase-wanted, checkin-needed, push-needed.
• Status whiteboard markers like "[needs review gavin]" and "DUPEME".
• Many comments that are only temporarily meaningful.

It would also make our process more transparent: there is always a first-level answer to "Why hasn't this bug been fixed yet?"

I started using Things in February when my coworker Jay Patel recommended it. I found it useful immediately, but my friend Alan Levin told me I had to read Getting Things Done to really understand how to use Things. He was right.

GTD is all about organizing actions so you notice them when they are possible. The book is full of great structures and tips for doing this, but I've taken advantage of the flexibility as much as the suggested structures.

My contexts

I use three sets of contexts to help me remember things where they are relevant.

• Frequent contexts: "home", "office", "errands". I use these not only to remember things at the right time, but also to plan rounds of errands and decide whether to go into the office on Fridays.
• Rare contexts: "Mozilla all-hands", "in Los Angeles".
• Anti-contexts: "read", "listen". These items are best saved for when I am disconnected, e.g. on an airplane or in a hotel room.

These contexts account for most of my tags in Things. I also make heavy use of the "scheduled items" feature to get stuff out of my way until it becomes relevant.

Multi-part projects

"Do taxes" crossed multiple contexts, so I had to break it down into individual actions. For example, faxing the forms was tagged as "office", because that's where I have easy access to a fax machine.

One tricky thing to categorize was waiting for my tax forms to arrive in the mail. GTD recommends having a special "Waiting For" list and checking it weekly, but I find it more relaxing to decide up front how long I'm willing to wait. Then I schedule a conditional item: "If I haven't received the tax forms by today, ask for a faxed copy".

Energy and concentration

The hardest actions for me to organize are the ones I can do anywhere I have my laptop and Internet access. Unfortunately, they're also the most numerous.

I tag these with the length of concentration required to make progress. This can be hard to estimate, but it's more relevant than knowing how long something will take in total. Processing my inbox took very little concentration, so despite being a large undertaking, it was a good thing to tackle while waiting for a phone call or just before lunch. In contrast, designing and implementing a new software tool takes concentration; if I start just before a meeting, I'll have wasted most of that time.

Weekly review

To keep myself from worrying that I'll forget about something that turns out to be important, I try to take some time on Friday afternoon to reorient myself. My weekly review checklist is mostly the same as the one in the book, customized for my inputs. The only unusual item on my checklist reflects my coding ability and flexible work environment:

Am I doing anything inefficiently? Can I automate it, improve my workflow, or delegate it?

Benefits

• Using GTD has unleashed more creative energy than I thought I had in me. You can see some of this in my last few months of blog posts. I believe this is a common experience for people who start using GTD, but I don't understand why.
• My anxiety seems to have decreased quite a bit, to the point where I might be able to get away with 5mg less Lexapro.
• It's possible for me to keep my inbox empty, which makes checking for new email less of a distraction.
• Processing all my stuff led me to discover five separate lists of movies I want to see. Now that I have a single list, it might finally make sense to sign up for Netflix.
• Instead of being bored while I'm on a train or airplane, I'm reasonably productive.
• If I get sick, I can stay home and still find meaningful work to do.
• The GTD workflow is simpler than the procrastinator's workflow.

Drawbacks

• It feels impersonal to manage every part of my life in the same system.
• I haven't figured out how to make priorities mesh with GTD. I can tag items as "saves me time" or "only useful if done soon", but I don't tend to look at those tags. Some people invent fake deadlines, but that seems dangerous.
• I'm still not good at setting aside time for projects that require significant amounts of concentration. Perhaps I need to create a habit of setting aside one day a week for that kind of thing, and make sure I have all the little things out of the way before that day.
• I now cringe every time I hear someone say "it's on my mental list".
• I have gained a new enemy: tools that impose bad workflows.

Took me three weeks to clean up five years of email, but I feel victorious.

I was hoping Gmail would congratulate me, but instead, it offers to send me to Google Reader. That's not really what I want staring at me every time I successfully process my email inbox. Who wants to write a Greasemonkey script to fix this for me?