notes-organization-organizEtdHandbook

  1. # Introduction

Etd (the acronym stands for "Emacs To Do") is an Emacs software package for keeping track of tasks. Some advantages of etd include:

This handbook describes how to use etd.

  1. ## 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.
      1. 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.
    1. Etd basic concepts
      1. Task A task is something that one could (potentially) do.
        1. Task attributes
          1. Subtask Any task may have associated subtasks which must be done in order to complete the task.
          2. 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.
          3. 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.
          4. 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

  1. #### 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.
          1. Quickness A task is marked QUICK if it is especially quick to complete, and LONG if it takes an especially long time to complete.
          2. Priority TODO

TODO do we have local priority, too? i guess yes, if priority is ordering, not scheduling

  1. #### Era (approximate scheduling) TODO
          1. Due date The date by which the task should be done.
          2. 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:

TODO: is this true? we also have nextReminder. Should we have a deferDate property, or is nextReminder that, or is SCHEDULED that? muteUntil?

  1. #### 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

  1. #### 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.
      1. 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".

  1. ## 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.

  1. ## 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.
    1. Statuses

Statuses and status-like tags:

Status-like tags that can apply to any TODO or WIP statuses (note: one task may be tagged with any combination of tags):

Predicates:

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)

WAIT(w) BLOCK(b) REQ(q) DELEG(g) MUTE(m) FOLLOWUP(u) SAY(a)
DONE(o)
CANCEL(c) HOLD(h)
  1. # Tags
    1. Special, predefined tags
      1. Status-like tags WAIT BLOCKED DELEG REQ

See the previous chapter, Statuses, for their meanings.

  1. ## FLAG The user wants to pay extra attention to this task.
      1. WARN The user thinks this task is at risk.
      2. QUESTION The user has a question about this task.
      3. 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.
    1. Prioritization, importance, urgency
    2. Importance
      1. LOW is inherited globally but not locally When computing global importance, the LOW tag is inherited by subtasks.
      2. If both IMP and LOW are present If both IMP and LOW are present (directly or inherited) on one task, LOW overrides IMP.
      3. 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.
    3. 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

  1. ### Defer When you defer a task:
    1. 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.

  1. # 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:

{
? BLOCKED*
? SAY*
        }
    - | {
      - NO_DELEG**: NO_DELEG->REQ
      - REQ*: REQ->DELEG, REQ->NO_DELEG
      - DELEG*:
        }
    - |? FOLLOWUP*
    - |? Muted***
? 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

  1. # Appendix: etd task properties In addition to the standard orgmode properties, the following task properties have a special meaning in etd:

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).

  1. # 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

  1. # 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

  1. # 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: