- # Introduction
Etd (the acronym stands for "Emacs To Do") is an Emacs software package for keeping track of tasks. Some advantages of etd include:
- powerful task representation can handle concepts such as tags, ordered subtasks, defer dates, delegation, dependencies
- efficient keyboard-centric UI focused on single keystrokes rather than key combinations
- readable plaintext exports designed for collaborating with others
- plaintext file storage format allows manual editing or interoperation with other software
- free, open source software
This handbook describes how to use etd.
- ## Relation of etd to orgmode Etd is a package that is implemented on top of orgmode, an emacs "mode". This allows users of etd to take advantage of the underlying extensibility provided by orgmode and by emacs. However, the word "etd" is also used for the underlying task management system implemented by etd. This task management system is designed to be portable and interoperable, with the goal that similar systems could be implemented on other computing platforms or even on paper, and that projects could be transferred between these various implementations via a standardized format for plaintext todo files. Initially, this standardized format will be a subset of orgmode's Org file format, with additional semantics.
- Status of etd Etd is in the process of being designed, and has not yet been implemented. For ease of reading, in this document, etd is described in the present tense, as if it already existed.
- Etd basic concepts
- Task A task is something that one could (potentially) do.
- Task attributes
- Subtask Any task may have associated subtasks which must be done in order to complete the task.
- Status A task status is a word describing what is going on with the task. Task statuses are written in ALLCAPS. For a list of predefined task statuses, see the chapter on statuses, below.
- Tag A tag is a word attached to a task. Tags are written in ALLCAPS. For a list of predefined tags, see the chapter on tags, below.
- Importance Importance refers to how important it is that you do the task. The IMP tag labels particularly important tasks, and the LOW tag labels particularly unimportant tasks; the 'default' unlabeled importance is more important than LOW but less important than IMP.
TODO local importance
- #### Urgency A task is urgent to the extent that there is not much time left to do the task, relative to how much time it will take to do. The URG tag labels urgent tasks.
- Quickness A task is marked QUICK if it is especially quick to complete, and LONG if it takes an especially long time to complete.
- Priority TODO
TODO do we have local priority, too? i guess yes, if priority is ordering, not scheduling
- #### Era (approximate scheduling) TODO
- Due date The date by which the task should be done.
- Defer date A date before which you don't want to think about the task. We use the SCHEDULED property of orgmode for this. This does double-duty as:
- the date you plan to actually start the task, or
- the date you next want to be reminded about the task
TODO: is this true? we also have nextReminder. Should we have a deferDate property, or is nextReminder that, or is SCHEDULED that? muteUntil?
- #### Dependency A dependency is when one task cannot be completed until another task is done first. Task B is said to "depend on" task A if task A must be completed before task B. Etd can only explicitly represent dependencies between tasks within the same file. However, if the user knows about another unfulfilled dependency, the user can mark a task as waiting for a dependency even if that dependency is not entered into etd(1).
1: Technically, etd can be said to make the [open-world assumption](https://en.wikipedia.org/wiki/Open-world_assumption) rather than the [closed-world assumption](https://en.wikipedia.org/wiki/Closed-world_assumption) with respect to its knowledge of what dependencies exist; in short, etd assumes that there may be other dependencies beyond the ones that you told it about.
TODO: alternate wording: is it invalid for a task to be in state BLOCKED if no unfulfilled dependencies are listed? No (there is no closed world assumption on tasks or task dependencies! A task can have more dependencies than are listed in the system, and by way of these it might be dependent on another task which is not listed in the system), but
NOTE: etd will auto-add the BLOCKED tag if it notices an unfulfilled dependency, and will auto-remove a BLOCKED tag that it added if all listed dependencies are fulfilled
- #### Ref Any task may have a "ref", which is a user-settable string that can be used to identify the task in some external context.
- Category A category is a set of (potentially related) tasks. In etd, each Org file defines one category, and each category is stored in its own file, and each category has one top-level heading with the category name.
A "context" is something like "tasks i have to be at home to do". To convey this, you might mark tasks that you have to be home to do with a "home" tag. Another way would be to create a category called "home" and put these tasks in that project. In this case the "category" would also indicate a "context".
An etd category could correspond to what the PARA system calls an "area", but it could also correspond to what the PARA system calls a "project".
- ## Project
All top-level tasks within a category file are called 'projects'. Note that these projects are themselves tasks, and can have statuses, importances, due dates, etc.
Note that we use the word "project" differently than some others; some other productivity systems define a "project" as any task which (a) is intended to be finished, rather than ongoing; and (b) would typically be accomplished over multiple sessions via doing multiple subtasks. By contrast, individual etd tasks can contain subtasks and may be accomplished over multiple sessions, like the "projects" of some other systems, and etd projects can be ongoing, like the "areas" of other systems.
- ## Global vs. project-local "Global" refers to the context of all tasks known by etd, across all currently loaded project files. "Project-local" refers to the context of a single project.
- Statuses
Statuses and status-like tags:
- NEW: newly entered into the system. May need to have stuff like importance, category set.
- IDEA: a potential future task; a someday/maybe. It has not yet been decided whether we are going to do the task in the forseeable future. We want to keep this task in the system, but we don't need to track it.
- ROADMAP statuses: things that we are planning to
- TODO: a task that we are planning to do in the forseeable future. We need to regularly review this task to make sure it moves forward.
- SOON: this task will be done 'soon'. Perhaps you have some other things that you need to do to get ready for the task; now is the time to start doing those.
- READY: a task that is ready to be done now
- NEXT: out of the ready tasks, some of them can be tagged NEXT to indicate that you plan to do those before the others
- WIP statuses: (W.I.P. = Work In Progress) things that are being worked on
- DO: a task that is being done
- CHECK: checking over/verifying/testing/validating the work that was done. This can be something we are doing, or it could be that we are waiting for someone else to look it over and approve it.
- FINAL: whatever needs to be done after the task has been checked and passed. For example, deploying software after it has been tested; billing clients after the client has signed off on a completed project; cleaning up a worksite; etc.
- CLOSE statuses:
- CANCEL: the task wasn't completed and we aren't thinking about doing it anymore.
- HOLD: the task wasn't completed but we might think about doing it later. Unless and until the user says otherwise, though, we don't want to think about it.
- DONE: the task was completed
Status-like tags that can apply to any TODO or WIP statuses (note: one task may be tagged with any combination of tags):
- WAIT: the task is unable to move forward at this time because it is waiting for something, such as waiting for someone to call you back. Typically, the user wants to review these tasks periodically to decide if they need to followup.
- BLOCKED: a subtag of WAIT. The task is unable to move forward at this time because it depends on some other task which is not yet complete.
- SAY: a subtag of WAIT. To move the task forward, you need to say something to someone the next time you talk to them, but there is no need to send them a message just to say it -- so you are waiting until you next talk to them. If you later decide that actually you should call/meet with them just for this, add a FOLLOWUP tag to make the task actionable. This can be used both for tasks where the whole task is to say something to that person, or also as an annotation to a task as a shorthand indicating that the next step towards completing the task is to say something to someone.
- DELEG: this task has been delegated to someone else, but still needs to be kept track of
- REQ: you need to ask someone else to do this task (you are trying to delegate the task to a delegee) NOTE: once you've asked the potential delegee, add WAIT to the task until you hear back. If they accept, then remove the REQ and the WAIT and add DELEG.
- FOLLOWUP: You need to followup with someone, for example someone you are waiting for, or to whom you have delegated a task. Even if the WAIT or DELEG tags have made this task not "actionable", adding this tag makes the task "actionable" again.
- Muted: Doesn't need attention right now. Some views won't show Muted tasks by default. Perhaps it is a task in TODO which is not slated to begin until much later. Perhaps it is a task which has been delegated to someone reliable, and does not need to be kept track of unless something unusual happens (such as the delegee getting sick, going on vacation, or quitting). Perhaps it is in TODO but it has been scheduled/booked/arranged for/entered into some external plan, and so does not need to be reminded about in this system. Perhaps the user just wants to put it on the back burner for a little while, but not to fully suspend it with HOLD.
Predicates:
- actionable: a task that you can do now. A task is considered actionable if it is READY, or NEXT, or WIP (work in progress), and is neither WAIT'ed nor DELEGated nor Muted; any task is also considered actionable if it has a FOLLOWUP tag.
- needsYou: a task that needs you to push it forward. A task is considered needsYou if is is actionable, or if it is ROADMAP and is neither WAIT'ed nor DELEGated nor Muted.
See also Appendix: etd task status statechart and list of predefined tags.
Status and status-like tag key bindings: NEW(n) IDEA(i) TODO(t) LATER(l) SOON(s) READY(r) NEXT(x) DO(d) CHECK(k) FINAL(f)
DONE(o) |
WAIT(w) BLOCK(b) REQ(q) DELEG(g) MUTE(m) FOLLOWUP(u) SAY(a) CANCEL(c) HOLD(h) |
- # Tags
- Special, predefined tags
- Status-like tags WAIT BLOCKED DELEG REQ
See the previous chapter, Statuses, for their meanings.
- ## FLAG The user wants to pay extra attention to this task.
- WARN The user thinks this task is at risk.
- QUESTION The user has a question about this task.
- MAYBE This task may not need to be done. How is this different from IDEA? IDEAs are "someday/maybes", things that don't have to be tracked right now. A task with a MAYBE is tracked, representing that the task of making the decision is itself on the ROADMAP, and then if it is decided to go forward, this task takes its place.
- Prioritization, importance, urgency
- Importance
- LOW is inherited globally but not locally When computing global importance, the LOW tag is inherited by subtasks.
- If both IMP and LOW are present If both IMP and LOW are present (directly or inherited) on one task, LOW overrides IMP.
- Relatively important task on an unimportant project When you have tasks within an unimportant project, you may have tasks which are "important" relative to the project. However, you wouldn't want these tasks to be highlighted as important in global views. To accomplish this, assign LOW importance to the parent project. In global views, the LOW tag will be inherited by all tasks within the project, and will override any higher importances. In local views, the LOW tag will not be inherited.
- The agenda views
The home rows keys are as follows. We present these in colemak form:
arst dh neio '
other 'big' keys include SPACEBAR, TAB, ENTER, BACKSPACE.
TODO
- ### Defer When you defer a task:
- if the task has a deadline, then if necessary, the task's era is set so that it contains the deadline (this ensures that you don't defer the task past its deadline). That is to say, if task has no era or if the end of the task's era is after the deadline, then the task's era is set to the longest era whose end is greater than or equal to the deadline. For example, if the task's era is MONTH, but the deadline is in one week, then the task's era will be set to WEEK. If the task is due today or overdue, the era will be set to the smallest era, NOW. TODO: we should hook the setting of DEADLINE to make this same adjustment to Era
- the task's nextReview is set to the current time plus the next smallest era below the task's era (or 1 day if the task's era is DAY or less). For example, if the task's era is MONTH, then the next smallest era is TWOWEEKS, so nextReview will be set to two weeks after the current time.
- the line representing the task in the agenda view is struck thru
- Task Dynamics The average rate of removing tasks from the tracked statuses (that is, the TODO statuses (ROADMAP, SOON, READY, NEXT), and the WIP statuses (DO, CHECK, FINAL)) must exceed the average rate of adding tasks to these statuses, otherwise over long periods of time, the total number of tracked tasks will grow without bound. When reviewing, if you feel that over the long-term, the average number of tasks in a status is growing, consider being less ambitious/optimistic, and remove some tasks from the tracked tasks.
A similar principle holds for IDEA tasks, however the problem is less acute because it's okay to have lots of IDEA tasks. However, if over the long-term the number of IDEA tasks keeps growing, you should probably put some of them on HOLD.
- # Appendix: etd task status statechart and list of predefined tags
Note: the transitions shown in the following statechart flow in the direction of progress or at least increasing committment, except for transitions to HOLD or CANCEL. But in actuality, motion in the direction of decreasing committement is possible as well, eg moving something from ROADMAP back to IDEA. Similarly, there is no edge from DELEG to NO_DELEG, but in reality it's possible to take back a task which was delegated.
Here is a textual representation of the statechart:
- OPEN*: OPEN->CANCEL, OPEN->HOLD
- NEW: NEW->IDEA, NEW->ROADMAP
- IDEA: IDEA->ROADMAP
- TRACK:
- {
- TODO:
- ROADMAP: ROADMAP->LATER
- LATER: LATER->SOON
- SOON: SOON->READY
- READY: READY->NEXT
- NEXT: NEXT->DO
- WIP
- DO: DO->CHECK
- CHECK: CHECK->DO, CHECK->FINAL
- FINAL: FINAL->DONE }
- GO: GO->WAIT
- WAIT*: WAIT->GO
}
- | {
- NO_DELEG**: NO_DELEG->REQ
- REQ*: REQ->DELEG, REQ->NO_DELEG
- DELEG*:
}
- |? FOLLOWUP*
- |? Muted***
- CLOSE
- CANCEL
- STOP: HOLD->IDEA, HOLD->CANCEL
- DONE
- : represented in the implementation as a tag (rather than as a status). Any combination of tags may be present at once.
- : not present in the implementation, just conceptual
- : represented in the implementation as a property (rather than as a status)
? X: an anonymous orthogonal region containing two states named X and NOT_X (in some cases there is a bidirectional transition between them and in some cases only a one-way transition, but we won't show that here); implemented as a tag named X |
actionable := ((READY or WIP) and !WAIT and !DELEG and !Muted) or FOLLOWUP needsYou := actionable or (TODO and !WAIT and !DELEG and !Muted)
orthogonal state tags spanning multiple states: WAIT BLOCKED DELEG FOLLOWUP
other tags: IMP/LOW URG QUICK/LONG FLAG WARN QUESTION MAYBE SAY
- # Appendix: etd task properties In addition to the standard orgmode properties, the following task properties have a special meaning in etd:
- nextReminder: a timestamp when the user should next be reminded about the task
- era: roughly the time during which the task is planned to be completed. The time in between reviews is also affected by this.
- muteUntil: this is the implementation of Muted; it has a timestamp-typed value. An item is considered Muted when it has a muteUntil property whose date in the future.
Era are represented by integers: 0: nil (same meaning and behavior as if a task doesn't have an era property) 1: NOW 64: DAY 72: TWODAYS 79: FEWDAYS 86: WEEK 94: TWOWEEKS 103: MONTH 116: QUARTER 132: YEAR 255: SOMEDAY (could also be called maybe/infinity/never)
The time between reviews is given by the next era down, eg a task with an era of TWOWEEKS (128) will be reviewed once a week (WEEK, 96).
- # Appendix: etd markup Etd supports the subset of orgmode's Org file syntax which is described in this appendix.
TODO TODO consider orgdown1: https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown1-Syntax-Examples.org
- # Appendix: etd cheat sheet TODO
Statuses and status-like tags and their hotkeys: New n Idea i Roadmap r Later l Soon s rEady e neXt x Do d checK k Final f Wait w deP p reQ q deleG g followUp u sAy a Mute m dOne o Cancel c Hold h
- # TODO
explain how category is for an intersection of project and area and sometimes context. explain how project in the sense of any multi-item task is instead handled by subtasks. explain dependencies. outline of UI/view explanations.
describe problems I had in the past and how this solves it, eg should snowplow, long-term important without deadline, putting a project aside, collaborating with others, etc
sample story that uses every feature, following a user's life over some period of time
note somewhere that orgmode sorts things WITHOUT ANY deadline as if they have the earliest deadlines!
TAB to see task in its actual file in another pane
era is kind of a rough scheduled, in two ways: The time is more approximate, and the semantics are less committed can IDEA/TODO/LATER/SOON/READY be looked at as an even rougher form of scheduling?
task dependency graph
some concepts:
- estimated effort/time to complete
- urgency (deadline - estimated time to complete)
- importance
- dependency ("blocked-by"?)
- priority (higher priority = we are planning to do this first)
- if A is blocked-by B, then does B inherit A's priority if A's in-itself priority is higher than B's?
- deadline (hard deadline; soft deadline)
- reminders
- level of committment (eg idea vs roadmap vs necessary)
- tags (topical)
- lists