Sorting voice recordings to fit the system

RobertWall

Registered
I'm still somewhat a newbie to GTD, but you asked for feedback - so here you go. :)

(I’m a little confused by the term “solve” a task. In gtd we try to complete tasks, and this does not necessarily mean to solve anything)

It's amazing how theoretically productive one can be while heading in the completely opposite direction of a solution, isn't it? :D

Not true that it is gtd to chunk actions into units that can be done in 2 minutes or less. However, if you determine an action will take 2 minutes or less, it is gtd to do it right away and not to put it on a list at all.

The logical exception would be for an action that can't occur in your current context for some reason. "Context" could be where you are, what you're doing, etc. DA even indicates that there are times when you shouldn't do 2-minute actions, like if there are a bunch of them and you're doing your Weekly Review.

It's probably good GTD practice to have some idea of how long a task might take. DA talks about this. If you're waiting for a doctor to call you in, you can call your mom to ask what dish you need to bring to Christmas (assuming you can have a short conversation with your mom :) ), but it might not make sense to call somebody to have a long phone meeting to hash out the particulars of a software project.

But I agree that's not a "context" - unless you subdivide your contexts into "Phone - Short", "Phone - Long", etc. And that begins to violate the "as complicated as required, but not more" GTD principle.

Also, it’s my understanding that “urgent” is not a context, although sometimes it is necessary to note the “must do today” tasks. I think tasks can be tagged as urgent, but urgent is not a context. How do you classify and handle urgent tasks?

Urgent tasks that must be done today go on the calendar. In fact, anything with a hard due date goes on the calendar. DA refers to this as "hard landscape".

The issue is when due dates get arbitrarily assigned to things that don't actually have due dates, and you "numb out" to the due dates. Due dates are only for things that will blow up if they don't happen on or by a particular date.
 

RobertWall

Registered
Also, I appreciate the discussion that processing an inbox is iterative.

Inbox processing is both iterative *and* recursive, although the recursion is theoretically limited. Here's your semi-recursive function in pseudocode:

Code:
foreach (item) in inbox {
  processInboxItem(item)
}

function processInboxItem(item) {
  if isTrash(item) {
    trashItem(item)
  } else if isReference(item) {
    fileItem(item)
  } else if isIncubatable(item) {
    incubateItem(item)
  } else if requiresAction(item) {
    while isNotNextAction(item) {
      nextAction = determineNextAction(item)
      processInboxItem(nextAction)
    }
    if canBeDoneInTwoMinutes(item) {
      doItem(item)
    } else if isDelegatable(item) {
      delegateItem(item)
    } else {
      addToNextActionList(item)
    }
  }
}

So you grab a piece of paper. It's an ad from the local orchestra, trying to get you to buy tickets for the symphony. You think you might want to go to their show, but you don't know. You need to know price and date, both of which are, for reasons opaque to you, not on the ad.

It's not trash. It's not reference. You *could* kick it out a week. It *does* require an action on your part, but "decide whether to buy tickets to the symphony" isn't a next action because it's held up by information you don't have.

Your ultimate action here is "decide whether to buy tickets for the symphony". If that's your project, your next action is "call symphony to get information re: price and date".

So now we call the function with "call symphony to get information re: price and date" as the item.

Not trash, not reference, not incubate. It requires action. But is it the *next* action? Well, it would be an easy two-minute action *if* we had the phone number. But that's not on the flyer either. So this isn't the next action.

We call the function again with "search Internet for phone number for the symphony".

Not trash, not reference, not incubate. It requires action. This is an action that you can do *now*. It takes less than two minutes, so you Google. You get the phone number.

Now the loop unrolls.

After coming back from the recursion for "search Internet for phone number for the symphony", we're back to "call symphony to get information re: price and date". It's a two-minute action, so we pick up the phone. The symphony is at 7pm on the third Friday in January, and it costs $50 per ticket.

The loop unrolls again.

Now we're back to "decide whether to buy tickets for the symphony". Is this the next action? Maybe. Maybe you don't have $100 in the budget for you and your spouse to see the symphony, so you can take a two-minute action to say "no" and close it out.

But maybe you want to ask your spouse. So "ask spouse re: desirability of attending symphony on third Friday in January @ cost of $50 each" is the action.

Back into the function.

Not trash, not reference, probably not incubate. This requires action, and needs to be tracked. Since the action of asking your spouse can be taken right away, you send your spouse a text message regarding the symphony. But unless they text you right back, now you've taken an action, and the loop unrolls.

"Decide whether to buy tickets for the symphony" is a project, with a next action of "waiting for spouse to give opinion re: desirability of attending symphony on third Friday in January @ cost of $50 each".

That goes on the next action list, the rest of the loops unroll, and you move on to your next inbox item.

It's kind of crazy to write it all out like that, since most of this happens instantly - but that's how the program would work. Recursive and iterative.
 
Top