Design todos
- todo.txt "priority" letters are also the "priority" here. They mean:
- A,B: sub-today
- C: today, definite (i guess that means deadline and scheduled)
- D: today, mb
- E: next 4 days
- F: flagged
- G: week
- H: fortnight/context/anytime (should soon go here?)
- J: soon/month/context/anytime (should later go here? what about todo, does that go here, or below? i'm thinking below -- todo vs idea is maybe too complex of a concept to be handled by a single-dimensional linear system, given that we also have to handle importances within IDEA and the importance of an IDEA could be greater than the importance of a todo)
- K,L,M,N,O: high importance project priority/importances 2 thru -2
- P,Q,R,S,T: normal importance project priority/importances 2 thru -2
- U,V,W,X,Y: low importance project priority/importances 2 thru -2
- Z: doesn't belong on this list
- view by simple task category. Not quite the same as view by era because schedule and deadline are included
- there is another priority, etdPriority, which can range from approximately 0 to 65535. This is used to represent an ordering (less than total, more than partial?) on lists of child tasks under a given parent node.
- view by era, pri, imp; simpleTask pri
- where we currently have MUTE in views, add deferred and (sometimes) scheduled
- mb have a key to flip between combined and un-combined views, and to flip between superagenda-group-by-outline vs superagenda-group-by-category. And mb a key to flip between importance filtering or not
- make a custom sorter that (a) sorts LOW below everything, then IMP above everything (note: this makes LOW take priority over IMP, as desired) (b) sorts by era? (c) sorts by importance? (d) sorts non-deadlines after deadlines
- if era is a rough scheduled, then perhaps we should constrain the choice of era by any scheduled as well as any deadline
- some views:
- planning: a view combining some of deep planning (but not IDEA), and needsAttention but not actionable, with actionable (both ready and WIP) and agenda, to facilitate selecting tasks to do, when, while seeing how busy you will be at upcoming times
- how is this diff from 'tracking' view?
- overload: ? only those things that you most need to know right now
- radar? upcoming?
- "anytime" view
- per-project overview
- per-project complete task list (how does the restriction work again?)
- https://orgmode.org/manual/Agenda-Dispatcher.html https://orgmode.org/manual/Agenda-Files.html: > or >> , org-agenda-set-restriction-lock org-agenda-remove-restriction-lock, org-speedbar-set-agenda-restriction
- all tasks, in importance sections, sorted, with WAIT/DELEG/MUTE in its own subsection
- look at my old views
- figure out what we are doing with whenEra, and with priorities
- user supplied date upon which a task becomes urgent. Does org mode support date typed properties? Maybe we can also do reminders this way
- read organizOntologies.txt organizJournal
also: check out https://develop.spacemacs.org/layers/+emacs/org/README.html#org-agenda-transient-state and also the leader key stuff at the top of https://develop.spacemacs.org/layers/+emacs/org/README.html#key-bindings-1 which i seem to have made unavailable somehow in my setup because SPC is bound to org-agenda-show-and-scroll-up and BACKSPACE to org-agenda-show-scroll-down and check out https://orgmode.org/manual/Agenda-Commands.html
- goal: "Not Missing Things" (not falling thru the cracks); or "keeping track"
list of buckets giving reasons to especially care about a task
place tasks that you especially need to remember (important or urgent or soon)) into a small number of buckets, maybe 12. Buckets are things like 'important and urgent'; they represent the reason that you need to especially remember this task. Whenever you encounter a task that you are afraid to delete from its original location (eg email) and throw into the task manager, maybe you need to add a bucket to this list.
Buckets so far:
- important
- urgent
- soon
- must
- quick (but not merely quick; higher priority than some other quick things)
and examples:
- email notifying you that a 1099 was issued and that you need to download it
- email that tells you something optional that you can do without negative consequences, that if you did it would make a small but not totally insignificant amount of money
- email that is not important or necessary but will be quick to reply to
- email reminding you of something that you really want to read, even though it is neither urgent nor important and demands no action of you
- email reminding you of something that you want to add to a list, eg:
- email reminding you of something that you dont necessesarily want to read, but that you want to at least add to a to-read list
- email reminding you of something that you want to say to someone else
Feature summary list
- defer dates, due dates, reminders
- readable plaintext exports designed for collaborating with others (so that you can eg filter and then present a task list to a contractor, yet maintain that list from the todo program, rather than making it a separate text file)
- recurring 'chores'. These need to bubble up automatically.
- plaintext source of truth
- delegation
- reviews
- hierarchy: category / task
- projects have an importance as well as tasks, and task importance is interpreted relative to the project: you can mark something as 'important' within a side project, without that making it show up as important in global views of important tasks
- reminders
- usable on mobile (possibly via web app)
- task/project templates
- tags
- tag hierarchy, especially for task status tags
- Kanban based on tags, which understands the hierarchy
- task dependencies
- foss
- ordered lists of items
- Maybe in org mode should have a small number of task templates : Pre-shower , Little thing around the house , todo today, To say to a certain person , etc Pre-shower razor , preShower soap
Non-standard task attributes
- when by era
- milestone
- dependencies
- local/global importances?
- reminders?
- numerical importance
- resolution (or just update/comment?)
Eras of time (timeEra)
Time eras are represented as integers using the following enumeration/convention:
1=today 2=tomorrow 3=next_few_days 4=week 5=next_few_weeks 6=month 7=quarter 8=year 9=someday 0=nil. In the UI the "0" key is used to assign this.
A floating point number in between two eras is treated as falling in the next higher era (eg 1.5 is in the 'tomorrow' era)
Most eras are subsets of each other: (today or tomorrow) \subseteq few_days \subseteq week \subseteq few_weeks \subseteq month \subseteq quarter \subseteq year \subseteq forever
taskType?
0=nil/ordinary 1=tosay 2=todg 3=chore 4=quick/anytime 5=errand 6=call/mtng 7=physical 8=atcomputer 9=meta
Questions
Questions about delegation
- should we have a 'requested' status that is after TODG?
Questions about priorites
- whence priorities?
- are priorities really just for ordering, or are they importances too?
- do we preserve my simpletask priority convention (e.g. C is "today, must")?
Questions about WHEN/eras
- how is WHEN used?
- are both important and urgencies by era? What about flags? Is a by-era flag used to mark something for an era overview?
- should we have era overviews? if so, how do they work? Are tasks auto-selected into the overview by importance/urgency, and/or are they manually selected into the overview with a flag?
- the value of urgency could be an era, the era in which the task becomes urgent?
- how to do custom when eras?
- are flags per-era?
- should whenTime and whenSeq be one field with two alternate enum values?
- for 'anytime', should whenTime be nil?
- if you have stuff like when =month how do you know when to advance that to week? Manual review? Actual dates are much better in that regard.
Questions about other planning attributes
Questions about statuses
- PLAN?
- task types/contexts such as call meet errand J/say K/quick/anytime/local?
Questions about implementation
- how to do reminders? probably will just use SCHEDULED altho that's annoying
- can you build an agenda view that filters by date on a custom date property?
Questions misc
- task field for self-action versus context dependent action such as talking to someone?
- mb want a way to categorize 'someday' ('zzz' in my lingo) stuff under 'projects' that represent timescales, e.g. "soonish", "this year"
- i already have primary/later/zzz, but i find i don't use them enuf, why not?
Statuses
ok, i'm a little lost there. What do i need the statuses to do, and what was wrong with the way i was doing them before? what do i need them to do:
- defining agenda views
- defining kanban
- sorting/prioritizing
- helping the user remember / track the statuses
what was wrong:
- too many statuses before meant:
- unwieldy ORs in agenda view defns
- takes too long to cycle through in the UI
- since kanban module didn't support ORs, couldn't fit all the necessary columns
- WAIT should have been ortho with completion, but wasn't
- DELEGATE (DG) should have been ortho with completion, but wasn't
- what else? i should read thru the rest of my old notes..
- this formalism doesn't represent different negative CLOSE resolutions by substates. Conceptually, an alternative representation would be for CANCEL to have substates representing different cancellation reasons. However, it may be better to make that an attribute, rather than cluttering the mental model with these extra states.
- our state naming convention is that a noun phrase state name describes the type of thing that the task (or the representation of the task within the todo system) is, whereas a verb describes the thing which is done in that state and which is completed (and in the past tense) to something that has left that state. For example:
- "Work in progress" is a noun phrase describing the task
- CHECK is a verb. When the CHECK state is occupied, a CHECKING activity (process) is taking place, and when the CHECK state exits successfully, the task can be said to have been CHECKED.
- the reason that the DELEG state is not named DEL is because the name DEL is often used in mathematics for the vector differential operator, and I am not currently aware of any meaningful connection between the DELEG state and that operator.
one design principal is to minimize the number of things in various stages of the system. This is the same principal as:
- putting things into a todo system to get it out of your head; the same principal applies to get things out of the todo system's head, both because it is sort of like a cognitive system itself, and because you are going to end up reviewing these things so it will take up your actual attention. You review the list of tasks in some statuses (eg TRACK) more frequently than others (eg IDEA), so it's also profitable to keep as many things as possible in the less-frequently-reviewed statuses (eg IDEA) and out of the more-frequently-reviewed statuses (eg READY)
- the kanban principle of 'minimizing inventory', adapted to the task management domain
- not precisely the same but "the sanctioned action is to cut". This is more of a design idea though. But one of the motivations of that design idea is similar (keep things simple to think about)
for each state, the design justification: NEW: partially formed tasks need to be marked as such, because the propositions 'declared' by the states of some of their fields may be incorrect; one consequence of this is that they need to be kept out of the other states otherwise they may erroneously appear overly highlighted in various views IDEA: keep things out of TRACK ROAPMAP: keep things out of READY SOON: trigger things dependent on this being in SOON (eg tasks involved in getting-ready-for the task in SOON) -- i feel like something that needs to trigger dependencies should be an actual state, so that we don't need to include the concept of tags in our model of dependencies (but we can include statuses); except for the need to trigger dependencies, this would just be a tag, a substate of ROADMAP READY: this is sort of the primal TODO; some superset of this is needed to fulfill the feature requirement of "look at the system and get a list of things i should consider doing now" (especially when refined by the 'actionable' predicate); by keeping ROADMAP (and SOON) out of this, we reduce the number of items shown in here DO: we can minimize the number of tasks in TRACK by prioritizing finishing things that we have already started (like DO) over things we haven't (like READY) note: is this really true though? does prioritizing a long task in DO over a short task in READY help this? i would think not really... CHECK: same justification as DO; by prioritizing these over DO, we can minimize the number of tasks in TRACK FINAL: same justification as DO and CHECK WAIT: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them DELEG: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them. This is different from WAIT in terms of task completion status, because here the task is not actually stopped. BOOKED: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them. This is different from WAIT in terms of task completion status, because here the task is not actually stopped. Why is it not just a tag? Because it applies to both SOON and ROADMAP HOLD: keep things out of TRACK and out of IDEA and out of OPEN CUT, DONE: to keep things out of the system, we need at least one terminal state, it's convenient to indicate whether the task was completed or not
TODO:
Perspectives
- there are sort of 5 functions here, which correspond to 5 places that tasks can be conceptually located.
- reminders to self, which are kind of like my simpletask
- 'tracked' tasks, which are things that you are actually planning to do soon, and which you need to keep 'in view'. Kind of like tasks in a sprint.
- These might be called 'active' tasks (can they be waiting-for or on-hold, though? probably? also, you can have side projects which you work on frequently, so they are perpetually active, but don't need to be tracked. Otoh in a sense you DO want to track things in side projects, you just don't want it to clutter up your view of your more necessary work and home projects). What i am getting at is: these are things that need to take up your attention, even if they are 'on hold' for some reason
- 'later' tasks, which are like sort of like tracked tasks in that you are planning to do them, except they are not 'soon' -- maybe they are dependent on a current task or maybe they can't be or don't need to be started for a few months, etc. Maybe waiting-fors live there? Many of these are things that are going to automatically transform themselves into 'tracked' tasks at some point, and others need to be reviewed so that they can be manually transformed
- someday/maybe tasks -- although someday/maybe is a poor word because some of these are more important/necessary than that. These are kind of like the issue backlog in an issue tracker. The set of these is intended to grow and grow because it has things like 'consider buying a juicer' along with notes on how to choose a juicer, and things like 'learn esperanto', along with important-but-very-not-urgent things like 'write a will'. They should probably have lots of varying importance levels so that you can periodically wade through the most important ones.
- tracker vs issue database vs help desk(responsiveness)
- at an overview level, that can maybe be simplified to 3 categories: reminders (like simpletask); tracked tasks; 'issue tracker'-like task db/archive. Am i missing anything?:
- we haven't talked about time-blocking type stuff at all yet, but mb that's orthogonal?
- what about 'goals' and mb 'themes' and overview-type stuff?
- not everything postponed indefinitely is a 'someday maybe'. For example, i got a notification that my email is taking up 86% of its allowed server space, so i have to clear it out someday. This definitely has to be done, but the timescale is indefinite and more than a month out. So i really dont want to forget about it forever, but i also dont want to do it this month. Similarly to backups.
- Maybe a snooze system is the best way to deal with this?
- Maybe bring back my 'must' tag (more generally, an enum for opt vs should vs must; opt (optional) could also be called mb (maybe))
- again, now we're talking about dealing with the long tail of far future tasks, rather than the near-term tracked tasks
- perhaps tasks can be someday without being maybe, and maybe without being someday
- so again, what other systems call 'anytime' tasks or 'low priority ongoing tasks' might be a separate category
- tiago forte and probably keepproductive seem to think of a 'task manager' as something to plan only what i would call the subset of 'tracked' projects over the next few weeks. Sort of: how i use simpletask (just to remind me what to do each day) + time blocking (that is, planning what to do over the next week or so) + mb a place to remember more distant tasks related to these projects, that might eventually be archived into some other storage if the project is placed aside
need places to put:
- todo.txt list of short-term things to remember to do
- list of current tasks/small projects (stuff like: xmas presents, tax provider for fund, go thru browser tabs, go thru todo list, work on getting permit, work on making task list for sarah, reserve hotel for jan, get vaccine boosters, get new contacts, punch list, send xmas cards)
- longer term planning for big projects (much of the house project stuff would go here)
- long-term ideas for later (someday/maybe but also more important stuff; like "there was something we were going to ask Gary to seal")
- things that are not urgent now but will be later (eg. future taxes)
- recurring tasks like laundry, backups
- sprint/epic-based task management, vs due date-based, vs priority-based, vs ordered queue
different tools for wip project management task backlog personal productivity
(C) backlog vs (workspace?) (see the connection to kanban inventory, wpietri sp big board; limit number of WIP). active vs waiting-on and followups. daily workspace? weekly, monthly too? different tools for: personal workspace (todo list); project management (other ppls tasks eg constructionproj; planning/scheduling far out -- tasks that are 'snoozed' and reappear later; also team task management); backlog (dealing with urgent tasks that will appear later; remembering midpriority should-dos and somedaymaybes and important but not urgents)
functions of organizational systems:
- remembering plans for future ideas
- remembering all sorts of notes and details
- remembering things you have to do
- remembering things you should do or may want to do
- planning and deciding what to do
- planning and deciding what to do and when to do it
- keeping track of when you are busy and when you are free
- motivating yourself
to put another way, systems for:
- capturing todo items, quick notes
- recall and reminders of todo items, quick notes
- knowledge base (notes archive) (pkm -- personal knowledge management, pim -- personal information management, pkb -- personal knowledge base)
- scheduling / calendar, and reminders
- project planning
- task prioritization
- task management / oversight incld. delegation
- project management / oversight
i might divide this into:
- portable capture and recall (simpletask)
- kb (knowledge base/notes archive)
- calendar
- everything else (what i am thinking of using orgmode for)
"someday" todos "anytime" todos
Use cases
some key activities include:
- quickly capturing stuff to 'new' (or might call it 'inbox')
- triaging, categorizing, assigning deadlines, and prioritizing those things
- scheduling stuff: assign 'when' dates; look at how cluttered various time periods are (some sort of 'upcoming'/'radar'/'forecast' view)
- checking in on pending/waiting-for/delegated tasks
- seeing what you are supposed to be doing now
- seeing what is in danger of not being done/what deadlines are coming up -- narrowing some of the above views to only the most important stuff
- looking thru projects and noticing things you forgot about
- reorganizing projects -- adding subheadings, moving stuff around, reordering stuff
- five GTD activites: capture, process, organize, do, review
- looking at things that may need to be done soonish and plucking a few of them into the current epoch
- planning what you will do including seeing how much time you have left and not overcommitting
Need solution for
- soon/should snowplow; often there are tasks that i should do soon (but are not must-dos); so on my simpletask i put them into soon eras (such as (D)). But then, since they are should-dos and not must-dos, they don't get done, and because they are pretty important should-dos, i deprioritize them a little but not too much, and so they end up sitting around (E), (F), (G). I call this a snowplow because it's the way that a snowplow creates these huge piles of snow at the edge of a driveway. soon/should is in contrast to someday/maybe; these are not tasks for the distant future, they are tasks for the short-term, and they are not 'maybes', they are pretty important things. For example, some construction is happening soon, so i should do a better backup of my computer just in case it gets messed up -- this is important enough and urgent enough that i don't want to deprioritize it much, but it's also something that i don't HAVE to do, and i'm pretty busy right now, so chances are i won't get around to it.
- "non important non urgent tasks that actually should be done sometimes soon not just someday maybe"
- i think this highlights the need to have distinction to things you are planning/scheduling to do soon, in the sense that you are pretty committed to doing them, vs things that are sitting on a todo list
- i guess this is when date vs due date, also firmness of when date
- it also highlights the need to distinguish between era and importance. This is another case of urgent but not important. Maybe that's all this is: urgent vs important
- another "obvious" solution is obvious solution is to have a separate set of A through Z priorities for important but not urgent tasks, and maybe another separate set for urgent but not important etc. Is that just floating point importances? Is that just a linear order?
- ok i made the 'flag' field a float to do this
- Are these "anytime" tasks? Or is anytime only if they are also quick?
- when you come back to a project after a long absence (either b/c the project was not urgent, or b/c you were too busy), and you review it, you need the system to surface more important tasks and not let you miss them in a sea of less important tasks and notes. Similarly for tasks that have a deadline far in the future, the system should be able to neglect the whole project for a long time yet still remind you periodically, and still warn you when the deadline approaches. Examples:
- ur accountant says you must do this quick task sometime within the next year
- ur lawyer says you must do this long task sometime within the next year
- important/later snowplow: another type of task that sits on my list at high priority is things which are important and in the midterm. I am worried that if i really just put them at midterm eras i won't look at them anymore, so i put them at soon eras even though i don't plan to do them soon. This one i think can be solved by snoozing/tickler/start date type stuff?
- the "separate set of A through Z priorities" might be helpful here too. Maybe each of the four important/urgent quandrant gets their own A-Z priorities?
- of course actually we'd like this priority to be a float, not an A-Z
- UI-wise could have A-Z and a-z be different somehow. Importance? Something else?
- maybe these A-Z are not priorities, but different levels of 'flagging' something that i need to keep an eye on
- maybe related to/replaced by reminder frequency?
- tracking things that other people were doing/supposed to do
- need better UI than my current orgmode setup (less steps to do common things)
- need a way to deal with what i used to put under (J): stuff to tell ppl. A 'say' file is not good enuf, this stuff has to be more readily accessible.
- how do i reproduce what i used to put under the (J) priority in simpletask? These were things i wanted to say to ppl. I would put the person's name using an @ list.
- say.txt file isn't good enuf, b/c it's not in simpletask
- @ alone without (J) isn't good enuf, b/c i need to have a way to review all of the things i need to say in one place to see if i need to schedule a conversation with someone who i thought i would randomly bump into, but didn't
- within projects want to be able to identify the NEXT task(s)
- at some point weeks away, if a certain person hasn't done something, I should follow up. How do I remind myself of this? This combines two things I have trouble with: tasks far in the future (without a hard deadline, so no calendar event entry), and dependent tasks (altho, is this example really dependent? it's just a waiting-for list item that is far in the future)
- my previous system had too much focus on prioritization of distant items, not enough focus on the near-term
- prioritization system too complicated (too many gradations of importance, etc)
- letting all those more distant items clutter up the common agenda views, making it hard to see all of the near-term/important ones
- need a way to get stuff off my todo.txt when i'm not about to do them in the next few days
- need to deal with when todo.txt gets overloaded
- probably just need efficiency UI to copy things from todo.txt->orgmode and orgmode->todo.txt
- sometimes i dont want to put an important task on my list b/c i am worried it may become crowded out by less important tasks
- sometimes i dont want to put a less important task on my list b/c i am worried it may participate in crowding out more important tasks
Situations and their solutions
- what i didn't have working well in my old todo.txt with semantic meanings was tracking things that other people were doing/supposed to do, and things far removed in time
- things far removed in time: defer dates
- the reason we want finer-grained importances/priorities for someday/maybes is that there are so many of those things that pile up over time that you need a way to sort and look at the most important ones quickly
- I feel like the two things that are stopping me from just jumping back into etd after a long absence are (a) i forget how to use the UI, (b) i just know everything will be cluttered up by a bunch of low priority things which are overdue. The solutions are: (a) more discoverable UI, (b) snooze functionality (to quickly push a tasks's defer date into the future), and views that dont show all of these low priority tasks that are constantly being snoozed
- system needs to be able to accept a bunch of tasks that need to be done far in the future when some other thing gets done that some other person is doing for instance "after stucco tell the General Contractor about all these things that relate to painting", and then to bubble up those tasks at that time
- esp. when you stop using the system for awhile, dont want lower importance recurring chores that you sometimes skip like "reconcile bank balances" to become overdue and clutter up your interface (or if they do, make them easy to dismiss/defer) -- this causes you to avoid using the system at all
- snoozing and importance solve this
- when either (a) ur hair is on fire with a bunch of urgent stuff, or (b) you are heads down in a big long project, you will stop using the system for awhile. Need the system to (1) survive not being used, and later be able to recover and absorb new information (new tasks, completed tasks, etc) with an easy UI, and (2) continue to remember to remind you about important, not-yet-urgent stuff from other projects when you start using it again
- discoverable UI, and importance solves this
- a way to be able to associate important to do items with projects, put them aside for a while, find them again when you come back to the project, or have them pop up if I need a reminder
- projects, listing things by project, importance relative to projects, and various dates solve this
- and what about subdates, eg 'evening'? a lot of ppl use that to indicate personal tasks (as opposed to work) but mb there's a better way to do that (eg areas)? i guess the point there is that when you are looking at your 'today' view the 'evening' stuff is down below, so while ur at work, it isn't bothering u. We can do this by using a floating-point value in whenTime.
- i guess the problem with whenEra-based priority buckets is this: you imagine that the things in the day bucket are being drained out, and when it's empty, some of the things in the week bucket drain into the day bucket, and similarly when the week bucket is empty some of the things in the month bucket drain into the week bucket. But what actually happens is that one or more of the buckets has an average rate of new tasks coming in greater than the average rate of tasks going out, and so accumulates an unbounded number of tasks, and buckets above that one never get drained or even looked at very much.
- i think the solution is to have regular reviews, with frequency proportional to the whenEra, to ensure that if there is a bucket that hasn't drained for awhile, that doesn't prevent the user from remembering the things in the buckets above it. Along with a user practice of trying to drain everything in TRACK.
Approaches
- users will generally 'live' in the (equivalent to orgmode's) 'agenda views'
- the structure of my old todo.txt with semantic meanings for letters worked pretty well (eras for the first letters, and flags, and then K and J for quick and say, respectively). Need better UI to make those ops quicker in orgmode.
stuff to think about
- think about how each of the old letter priorities are represented in the new system
- we probably got dates covered via defer dates, soft deadlines (finish dates), hard deadlines, reminders, actual calendar events. Maybe a waitingfor list and a tickler file could have solved these problems, along with a list of tickle-ed items.
- priority is different from importance;
- mb priority is how soon you are going to work on something (neither importance nor urgency on its own determines this)
- or, mb priority approximates an ordered list
some of my immediate use cases include:
- need to make a todo list for the Oot project
- need to make pld (programming language design; and also a little plt, programming language theory) learning todo list within the Oot project
- todos for this project
- house task list
- house task lists present a unique opportunity for computerization because it should be sorted by both room and trade for example guest bedroom, electric
other ppl keep it pretty simple. Eg some of them only have two gradations of importance (normal and high), some work mostly out of things 3's inbox or today view, some treat 'today' as meaning 'this week' and only plan for this week, etc. They don't care about status ontologies, they focus on just having a list in each project of tasks they thought of, and then assigning some of those tasks to nearby epochs.
- note simpletask's idea of @lists and +tags (as generalizations of @contexts and +projects; e.g. a waiting-for list can be @waitingfor even tho it's not a context; and you can say "@Call +DavidAllen? regarding +GTD" even tho the two +s are not projects) (although some would make this @Call @DavidAllen?