Unfiled Actions

Yeah, I just create a special project for these one-offs and keep them all in there.

I’ve enabled multiple manual next-actions in the KGTD settings so I can force them all to be NA’s. Luckily the script works fine for me.

Daven: maybe you also need to enable multiple NA’s in the settings?

Our man Ethan writes:

I use Unfiled Actions to store tasks coming in from, for example, your PDA and iCal

Shouldn’t these go to Inbox instead?

I wholeheartedly agree that it would be very wrong to have things just appear in an actions list without first hitting your inbox (for a later “do it, delete it, or put it on a list” processing cycle) but why do you need to bypass the inbox anyway?

It seems like you are somehow using Unfiled Actions as a pseudo-inbox. This seems strange to me. Making it as easy as possible to populate the inbox (including things like quicksilver) for a separate do-it/delete-it/add-it-to-a-list step later is the absolute heart of the GTD process to me.

Before I continue with my only gripe: I love the scripts. This is an outstanding piece of work and I’m only bringing this up because unreported bugs or misfeatures will never be fixed. I’m not intending to whine or look a gift-horse in the mouth, but it seems worthwhile to explain as clearly as possible what I believe is a relatively small but important design flaw.

For me, this ONE thing is making KGTD feel like eating an otherwise perfect egg-salad sandwich with just a tiny little speck of eggshell in it. (The “one thing” being the requirement that every action has a project).

I believe your intent in forcing a project to be associated with every action is ultimately to make review-time easier. I suspect the intent is to make “which action do I next” decisions easier simply by ordering their parent projects.

One of my big take-aways from GTD was that “what do I do next” decisions should be made based on context and energy level, and not on the relative importance of projects. Review time is when you ensure that projects are making forward progress.

What is the value of forcing people to create “dog maintenance” projects?

Creating a catch-all project for “singletons” is a valid workaround and just a one-time annoyance, but not being allowed to leave the “project” pulldown empty is a minor annoyance that is repeated for every singleton action that ever makes it to my inbox!

Singletons are a relatively small percentage of my inbox items, but they exist and will continue to exist.

For completeness, here’s how I use KGTD:

1. Random “stuff” gets added to one of my inboxes (in my case, the KGTD Inbox, my moleskine notebook, or my physical inbox on my desk).

2. Periodically (at least once or twice a day) I process my inboxes top to bottom: do it, delete it, or assign a context and OFTEN a project (today I’m forced to always assign a project, but I use a catch-all project for singletons). Some things do just become calendar entries — those items and ones I do right then are simply deleted before going to the next item on the list.

3. When I’m looking for what to do next, I look at my Actions page and pick and choose what I want to do based on context (the “@” lists) and motivation/energy-level. I look at the project column, of course, and often select something because I want to work on that project but it isn’t the primary decision point for me.

4. At review time I’ll look at the Projects, Someday-maybe, and Actions pages to make sure that I’ve really got manageable bite-sized “next actions” on my list, that things aren’t sticking around too long, and that my projects are moving forward. During review time I often add additional actions to my projects, as well as re-order items (ensuring that the true “next action” is at the top of the list).

5. Clicking the sync button only moves PROCESSED items out of the KGTD Inbox. Processed for me means a context assigned. Items that have no context assigned haven’t been processed. (The setting to automatically move things from inbox to an “Unassigned Actions” project seems totally misguided to me.)

Sorry for the long post, but it seems like your workflow must somehow be different because of your insistence on a project assignment. Your rationale above was because of things showing up in Unfiled Actions, which I agree is bad. Is there any other reason? If those things went to Inbox instead of Unfiled Actions would your objection still stand?

Thanks again for the great work!

Ethan, I don’t mind there being a special “Unfiled Actions” project for technical reasons.

However, I would like to be able to make a special “one-liner” project, in which everything gets hilighted as a next-action, and that (apparently widespread) desire isn’t unreasonable.

To address your comment: while maintaining the dog may technically be a project, from my perspective it’s an extra piece of unnecessary overhead that slows my system down.

Especially if it’s the neighbor’s dog, so there’s no point in a project for the pooch. I mean, what, you’ve never been asked to do one little oddball favor, once, that doesn’t fit in your existing set of projects?

It’s nice that you’re looking out for me, but the design of your software is not the place to be forcing your idea of best practices on your users. :) Not, at least, at the cost of interrupting my workflow. Let me add a next action, see it, do it, and cross it off.

JoshD said: “I would like to be able to make a special “one-liner” project, in which everything gets hilighted as a next-action, and that (apparently widespread) desire isn’t unreasonable.”

i. Create a Project called “one-liner”.
ii. Go to Next Action Settings, and set ‘Allow multiple manual next actions’ to ‘true’.
iii. Enter ‘Clean neighbor’s dog’ in that project, assign a context, and with the action selected, run the ‘Next’ script.

I’m not clear what else you’re looking for than this?

The thread started out with ‘Being forced to create a project for every next action does not seem to mesh with the GTD philosophy.’ But the simple answer is, you aren’t forced to. You just need to create a project for each project, and (if you want to) one other: the projectless actions project, and stick all the one-liners in there. You can assign them next action status, you can assign them contexts, you can check them off, you can do everthing with them that you can do with ‘official’ project actions. But OO is a strict hierarchy, so everything has to go ‘somewhere’, even if it’s in a project called ‘nowhere’.

Well that’s how it seems to me anyway… And I’m enjoying wrex’s detailed explanations of how he uses kgtd. It’s not easy to make a perfect tool, and I think a lot of us agree this thing is damn near perfect, so tweak tweak tweak!

Ethan said:
I’m also considering auto-assigning a project other than unfiled actions to certain tasks, i.e. an “autoassign to singletons” type behavior. Not sure yet.

I like this idea, Ethan … possibly a suffix like the - and + in the contexts. Affixed to a project name, it would mean “every item here should be a Next Action”.

For that matter, a context suffix that would automatically make everything be a NA would be nice, too. Some of my Projects/Task Groups (the more I think about it, the more I see people misled by the title Project) have items that can be done at the same time, and should be.

An example from my Home Ec class (well, what it should have been, instead of learning to fringe placemats - ugh!): when you are sewing something, often there are several independent tasks you can do first, before moving to the next set. On a dress shirt, you can assemble the collar and cuffs long before you have to attach them to the shirt. I would go through the instructions and change the order, grouping the things I could do first as Step 0, then the things that could be done immediately next as Step 1, etc.

Life is like that, too — if I’m planning to lead a seminar at a conference, I can research my topic and contact the conference organizer at the same time — they are not sequential. They can both be Next Actions.

As KGTD is set up now, it is hard to see beyond the “every task must be assigned to a Project” / “do only one action at a time” process. I’m finally reading GTD, and the book doesn’t imply a lock-step process. I know KGTD doesn’t have to be used so rigidly — I don’t — but there are plenty of people who won’t RTFM and condemn the system because of that.

I fear I’m beginning to sound like I’m dictating to you, Ethan, but I don’t mean it that way. I’m just philosophizing.

Oh, here’s my fantasy “fix”: can you make KGTD take up less screen space? I have it open all the time, and it hides too much of my desktop picture. Just kidding — it wouldn’t be nearly as useful if it didn’t contain all the info, in a font size I could read.

—Liz

Ethan:

Been following this thread and just want to record that I like the way kGTD works at present:

New actions get placed in a dedicated inbox for later processing - by QS, LB or manually - and not be allocated to projects or contexts on input (as per GTD);
Technically unresolved actions get placed in unfiled actions which is then viewable at the top of the projects section.

I am not sure where the doubling up is - new actions (obviously unallocated) should be in the Inbox not the Project sections. Once they have been processed and allocated to a Project/Context they get “filed’ in the respective Project. If there is a technical “anomoly” they get placed in !Unfiled Actions for resolution. Good GTD practice.

Regarding the singletons/unfiled actions debate (which seems to be the cause of most of the issues with using/understanding kGTD) I currently use Michael’s approach and have a project called “1 Time Actions” which ensures that it is listed at the top of Projects (don’t have unfiled actions) and it works fine - am also happy if you create a predfined project for them but don’t believe they should only be in the Actions section but should also be in the Projects section, as this is where the review(s) should be conducted and tracking takes place. Actions is where the work happens.

I agree that unnamed projects are not a good idea as all that is doing is hiding the fact that the child actions actually are part of a “dummy” project.

Keep up the good work - you have it where I want it from my understanding and implementation of DA’s book - just need speed, stability and doco (probably in the inverse order).

Liz:

If you have 1 project which has various parallel processes and want to process next actions for all of these, then use sub-projects - this is true for the majority of my “projects”.

Cheers
John

I, too, am displeased with KGTD’s treatment of unfiled actions. Any progress on this so far?

I really dislike having to use a pulldown menu to assign project headings. Especially since leaving the project blank seems to cause problems in synching…