TODO
- read organizOntologies.txt organizJournal
- "Not Missing Things" (falling thru the cracks)
- 4 trinary conceptual dimensions (so 81 states), which is too many states, but only a small subset of these are valid Todo statuses (certainly less than 26) (it would be nice to just have 3 dims (27 states), but I think that's too few)
- the 4 dims are used to have axioms whose theory which explains/defines which todo statuses are valid, amongst other things
- even though the software operates with the todo statuses, which have a sort of idiosyncratic structure between each other, it is explained with the 4 dims, which is somewhat simpler
- as of this writing, below i have 23 states, but i think we can cut some of those: NEW(n) IDEA(i) TODO(t) WIP(p)
ASSIGN(a) DELEG(g) LOOK(l) RELY(y)
WAIT(w) BLOCK(b) PAUSE(z) REQUIRE(q) | HOLD(h)
ROADMAP(m) READY(r) CHECK(c) FINISH(f) BOOKED(o)
STEW(s) FOLLOWUP(u) REVIEW(v)
- can mb remove the 'microactions' like STEW FOLLOWUP REVIEW LOOK, and maybe ASSIGN, for example
- mb CHECK, FINISH, except that CHECK is higher priority than WIP (and WIP should be higher priority than READY), so there is some semantics to CHECK (and same goes for FINISH, which is even higher priority than CHECK, although i'm not sure if we need both CHECK and FINISH); otoh the same goes for WIP vs READY, so maybe that's enuf
- also FOLLOWUP is different from WAIT in that it is actionable; could just create a new task for the followup but would be more convenient to have a FOLLOWUP status
- is importance or urgency or some combination one of the 4 dimensions? No, they are ortho to the TODO statuses (even though they are also trinary)
- similarly, "when" ("scheduled") dates, due dates are, like imp urg, 'planning' attributes that are not one of the 4 dims
- should map out the todo states (which ones are subsets of each other), and for each one, give its attributes on the 4 dims
- so what are the 4 dims? i think 3 of them are: completion/openness, activity (stop or go), actionability (or more generally, what you/the system have to do next)/needs attention. Not sure what #4 is?:
- committment/defineness (could would/toconsider should will must? or something trinary encompassing these)? or, related,
- firmness (eg is 'scheduled' a reminder or a when date? is the due date a hard deadline? when we say this is a TODO, does that mean we have selected/committed to it/we definitely (or close to that) want to do it?)
- trackedness (tracked/untracked/later)?
- needs attention?
NEW: not started
started (any open), any activity, actionable, tracked |
IDEA: not startedstarted (any open), go, actionable?, untracked |
TODO: not startedstarted (any open), any activity (eg dep, ready), actionable?, tracked |
WIP: started, ready, actionable, tracked DONE: done, n/a, n/a, n/a NIX: done::nix DELEG: started?, go?, not actionable, tracked RELY: started?, go?, not actionable, later? untracked? WAIT: any open, stop, not actionable? or is it needs attention b/c followup?, tracked BLOCK: any open, stop, actionable?, tracked or later PAUSE: any open, stop, not actionable, tracked or later REQUIRE: any open, stop, not actionable, later HOLD: any open, stop, not sure about actionable?, untracked ROADMAP: not startedstarted (any open), not actionable? (not READY), tracked? later? |
READY: not started, actionable, tracked? (NEXT?: not started, actionable, tracked?) CHECK?: started, actionable, tracked BOOKED: not startedstarted (any open), not actionable and doesn't need attention, tracked? |
a lot of question marks there, suggesting that the choice of 4 dims either isn't quite right yet, or aren't formalized enuf yet
- 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
- reminders are different from scheduled dates (but could deal with that via 'reminder' tag/properties)
- need onto for microactions; stew, followup, dec, etc
- need to list view ontology ideas, and to design views
- mutt-like sequence of single letter ortho status indicators (i vs I, etc) in each agenda line?
- mb do redesign in view of orgmode's/paper's/todo.txt's limitations
- want system applicable to paper, too
- no computed properties
- orgmode has statuses, tags, priorities, properties (drawers?)
- even bulletjournals have todo statuses vs 'signifiers'
- relationship between ROADMAP and either tracked or needsAttention? For example, do you only track things on the roadmap, or only pay attention to those tracked things on the roadmap?
- whenSeq is not quite but sortof a subset of READY or of ROADMAP -- in the sense that first you decide to do something, then you assign it to the current sprint. It's not quite, because something could be assigned to an upcoming sprint either before or after it is READY. In any case, you could give whenSeq keyboard shortcuts of digits in the same keymaps where you have the letters for todo statuses
- there's something in between IDEA and something definitely on the roadmap/in a sprint: "to consider", something that you are not sure if you are going to do, but you definitely are going to consider it at some (mb only slightly) later time; this is sort of a "definite maybe". For example, when renovating a house, you might thin "while we have that wall open, maybe put in ethernet cable"; maybe it's a good enough idea that definitely want to consider it, but you need to see how much it will cost and how long it will take, and maybe for some reason that information can't be available until some later step in the process.
- need to consider implementation difficulty of stuffing everything into TODO status vs different properties vs tags
- could even have 'derived' TODO statuses that represent important combinations of various ortho properties
- ASK is a nice short word, maybe should be a state. Could be used instead of ASSIGN or REQUEST. Could also be used for TOCONSIDER.
- definiteness (or committment) ortho status: idea, should, toconsider
- https://orgmode.org/manual/Speed-Keys.html
- is there a way to filter agenda views by a custom Lisp expression? "Custom agenda commands can preset a filter by binding one of the variables org-agenda-tag-filter-preset, org-agenda-category-filter-preset, org-agenda-effort-filter-preset or org-agenda-regexp-filter-preset as an option" -- https://orgmode.org/manual/Filtering_002flimiting-agenda-items.html
- you can filter by regexp
- ideally, upon invoking an agenda view, would compute virtual tags for each potential item using a custom hook, then filter based on those
- yknow, my previous system ontology wasn't far off. whenTime really can be a subset of priorities, and later priorities can be used for relative importances within less important tasks. Categories can be used instead of areas/projects. We can stuff all those ortho things into todo statuses. We really just need some better keybindings, especially for 'snooze'/'defer'.
- statuses
- what are the design goals for statuses?
- keybindings
- start implementing. See how far you can get just using orgmode and not programming much
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: area / project / task. Any of these can have levels (limited or unlimited?) of sub-Xs, eg subareas, subprojects, subtasks
- 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
- collaborative features: task request/acceptance/assignment
- foss
- 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
Core data structures
Area data structure
- id: primary key
- name: string
- parent_area: reference to an Area. Nilable.
Item data structure
- id: primary key
- item_type: can be TASK, NOTE
- parent_heading: reference to a Heading. Nilable. Exactly one of parent_item, parent_area can be nil.
- parent_project: reference to a Project. Nilable. Exactly one of parent_item, parent_area can be nil.
- other_parent_projects: array of reference to Projects.
- parent_area: reference to an Area. Nilable. Exactly one of parent_item, parent_area can be nil.
- previous_item: reference to an Item. Nilable
- next_item: reference to an Item. Nilable
- ref: field for a custom external ID (for example the task numbers in a list of tasks that you sent to a collaborator). Nilable.
- creationDate
- lastUpdated
- owner: who owns this task
TaskTemplate (subclass of Item)
- duration (dur): Can be an era or a date-duration. How long you expect the task to take (given its current progress; so this gets smaller when you work on the dask). The default is nil, the 'quick' tag is equivalent to 0. Nilable.
- supassigner: person who assigned this task to you. Nilable.
- supassigner_task: reference to the assigner's version of this task. Nilable.
- subTasks: reference to an ordered list of Tasks. Nilable.
- must: floating-point. Whether the task is optional or a necessity. The default is 0, the 'must' tag is equivalent to 1.
- importance (imp): Floating-point. How important it is to do the task. The default is 0, the "imp" tag is equivalent to 1, the 'low' tag is equivalent to -1. Importance of a task is interpreted relative to its parent project, if any.
RecurringTask (subclass of TaskTemplate)
- recurDelay
- recurDelayFromDone: bool. If False, then recurring tasks bubble up with a certain delay from the last time they bubbled up, regardless of whether you finished the previous instance or how long it took to finish it. If True, then the delay clock only starts ticking when the previous instance is finished.
Task data structure (subclass of TaskTemplate)
- whenTime: Can be a timeEra or a date. When you intend to work on the task. float. Nilable.
- whenSeq: seqEra. When you intend to work on the task. float. Nilable.
- start_override: when the task should be started
- softDeadline: Can be an era or a date. When you hope to finish the task. Nilable. (was called: finish (fin))
- hardDeadline: Can be an era or a date. Hard deadline. Nilable. (was called: due)
- defer: Date. The task is in a 'snooze' state until this date. Nilable.
- priority (pri): Floating-point. Like a 'when', but timeless; that is, used to order when you plan to work on tasks without reference to dates/eras. Nilable.
- reminders: Array of dates. Reminders for this task will be issued on each of these dates. Can contain past dates; a date is only deleted from this array after the reminder is explicitly acknowledged.
- instanceOfRecurringTask: if this is an instance of a recurring task, then a reference to the RecurringTask?. Nilable.
- urgency_override: How urgent it is to work on the task, if it is to be finished by the due date. Nilable.
- subassignee: person to whom you assigned this task to. Nilable.
- subassignee_task: reference to the assignee's version of this task. Nilable.
- isProject: bool. Data-structure-wise, a 'project' is really just a task but for UI purposes they are treated differently (displayed as a list of projects, etc). (todo: is this really true what with global importances?)
- isAction: bool. Data-structure-wise, an 'action' is really just a task but for UI purposes they are treated differently (not displayed as freestanding tasks in queries, but rather only displayed as part of their parent task).
- tracked: trinary. How much this is a task that the user needs to keep track of (high) vs how much this is just an idea on a list of things to possibly do, that doesn't need to be recalled unless the user looks for such things (low)
- superTask: reference to a Task. Nilable.
- whenFirmness: float. default 0. >=1 means firm when (that is, you are pretty committed to working on this on the when date). Note: this captures my (C) vs (D) in my simpletask system
- flag: float. default 0. >=1 means 'flagged'. Flagged things are items that you want to keep top-of-mind for whatever reason. Higher 'flag' value means more top-of-mind.
- health: how are we doing on this task? An integer. Health enum. Nilable.
- taskType
- quickness: float. -1 is slow, 0 is medium (eg go to the bank), 1 is quick (eg send this short email). Nilable.
- votes: float
- dependsOn: array of references to Tasks
- dependedUponBy: array of references to Tasks
- milestone: string. Nilable
Computed properties:
- For any field that can be an era or a date, you can convert it into an era
- start. startOverride if not nil, otherwise start_recommended
- startRecommended. finish - duration. Can be an era or a date. When the task would have to be started in order to comfortably finish it. Nilable. Computed from 'finish' and 'duration'.
- urgency. urgency_override if not nil, otherwise urgency_recommended
- urgencyRecommended. 1 - (due - current_date)/duration.
- parentProjectMaxImportance: the highest importance currently assigned to any task within the parent project (including tasks that are descendents but not direct children of the parent project), or nil if no parent project. Nilable.
- parentProjectGlobalizedImportance: the current globalizedImportance of the parent project, or nil if no parent project. Nilable
- globalizedImportance: the product of (this task's max(importance,0) / max(parentProjectMaxImportance,0)) with max(the parent project's globalizedImportance,0), or if no parent project, just importance
NOTE:
- implementation difficulty of computed urgency probably too great; mb go back to just manual URG
- implementation difficulty of computed importance probably too great; mb go back to just manual global IMP, and then also add a local priority
- can just go back to letter priorities for local priority -- can use things past M
Note data structure (subclass of Item)
- priority (pri): Floating-point. Like a 'when', but timeless; that is, used to order when you plan to work on tasks without reference to dates/eras. Nilable.
- text: string
Heading data structure
Computed property:
Person
- id: primary key
- handle: an short, easy-to-type nickname with no spaces. string. Unique across all Persons.
- name: the person's "full" name. string. Nilable.
- email: the person's email. string. Nilable.
- phone: the person's phone number. string. Nilable.
- organization: organizational or group affiliation. string. Nilable.
- custom_info: other info (such as contact info). string. Nilable.
- user: a reference to a user account, if any. Nilable.
- ref: field for a custom external ID (for example the person's URL in some online contact db)
User
- id: primary key
- person: a reference to this User as a Person
- groups: a set of (group, role) giving groups where this user is a member of, and their role in that group (computed from Group members)
- taskSubstriptions: array of references to Tasks
- starredTasks: array of references to Tasks
Group
- id: primary key
- name: string. Unique across all Groups.
- members: a set of (user, role).
- custom_info: string. Nilable.
- ref: field for a custom external ID
CalendarEvent
todo
calendar events have a project field, etc (mb they are even a subtype of task, or maybe both tasks and events share a superclass?)
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
Eras of sequence (seqEra)
Used for sprint-like ordering/classification
1=now/current 2=next few 3=current sprint 4=next sprint 5=near/soon 6=planned to do sometime 9=not planned yet/idea 0=nil
hierarchy:
9unplanned 8planned
|
4current,5next,6second,7near
|
1now,3nextfew
|
2next
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
- parent_project implies that projects are NOT just tasks; do we want that?
- do we want to forbid a project under a non-project task?
- mb, esp. if importance is project-relative
- do we want to have a max hierarchical depth for areas, projects? eg reify subarea, subsubarea, subproject, subsubproject, and not allow further 'sub's under those? Seems limiting but could be useful for UI. Similarly, do we want to limit the depth of headings, or the interleaving of tasks/projects/headings?
- mb, esp. if importance is project-relative, so that we can add fields for these, so that we can easily compute global importances
- should there be a small limit to number of levels in any one of these? May help with UI. 7 would probably handle anything but that's a lot. The old 7+-2 rule might suggest 5, but that's still a lot. 2 is probably too little; think of construction: smith-house/second-floor/master-bedroom/bathroom/shower. That we're dealing with numbers as big as this suggests that maybe we just shouldn't have a limit. If i had to choose now, i'd say have a limit, and the limit should be 5. BTW APA defined 5 levels of headings: https://owl.purdue.edu/owl/research_and_citation/apa6_style/apa_formatting_and_style_guide/apa_headings_and_seriation.html . The typical scheme for different types of heading characters has 5 levels: I.B.3.d.v (i think i prefer 1.2.3.4.5 tho; see https://typographyforlawyers.com/hierarchical-headings.html ; also, that way if you change the level of a heading, it doesn't change).
- we have stuff like milestones, phases, subphases, etc, and then we have 'eras'. Should we rename era to timescale? Should we use the words epoch or stage or epic for something? Is a milestone different from a phase/subphase? In general, we have time-based segmentation (eras) and custom planning segmentation (phases). And then there are things like 'sprints', which are a third kind of segmentation; in that sort of system would like to mark tasks as 'current' vs 'next'/on-deck vs 'near' vs 'far' (or mb just now/near/far).
- in geology we have "Eons are divided into eras,[2] which are in turn divided into periods,[3] epochs and ages"
- combine defer and reminders: should we just use the defer date as a 'next reminder', and ack reminders by snoozing?
- combine imp and must: should we delete 'must' and consider it redundant with 'imp'?
- the urgency formula might not be quite right -- currently, a long task which is projected to be overdue by one day is less urgent than a short task whic is projected to be overdue by one day, is that what we want? Also, it's a little counterintuitive that a task that we have just enough time for is urgency 0; maybe we should add 1; but if we do that then tasks which are due today have urgency 2, which is also counterintuitive.
- should we have a 'requested' status that is after TODG?
- should we combine defer dates and reminder dates
- task field for self-action versus context dependent action such as talking to someone?
- computed task property for whether or not something is urgent in an era?
- whence priorities?
- is this overdesigned?
- 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?
- on the task list view, when there is subsubsubarea and subsubsubprojects, how many levels of hierarchy to show by default? All of them?
- the value of urgency could be an era, the era in which the task becomes urgent?
- should we reify subprojects and add a field to tasks for that, to assist in computing global importance?
- should all due dates be hard deadlines? should we use the word deadline instead of due date?
- instead of just isTracked, should be have tracked vs untracked/later vs somedaymaybe?
- is next action is subtype of the ready task status? So we would have a status called NEXT
- in order to simplify, may want to avoid sounds-similar-but-subtly different things; e.g. inactive vs on-hold vs waiting-for vs later
- should we have tags that can have statuses, like a 'waiting-for' tag with status:on-hold, so that when you tag a task with that it makes the task status on-hold?
- how to do custom when eras?
- are flags per-era?
- many of the fields on task could be unified under a few types: tristate, float, enum, dates, and hierarchical tags. Maybe should have generic facilities for these?
- no, more than that; i'm thinking of a more powerful/abstract UI that is based on these things. Some parts of the above data structure schema would merely be a default profile loaded into this system. Profiles could be project-specific.
- so shall 'project' also mean something like what it does in an IDE, a grouping of items, also grouped together with their UI settings (and build settings, but not quite sure what is the equivalent to that in todo-system-land; perhaps the assignment of special roles to some items in the grouping?)?
- should whenTime and whenSeq be one field with two alternate enum values?
- for 'anytime', should whenTime be nil?
- 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?
- 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.
statuses
- task statuses (3 kinds; status of task, status of your activity on task, status in system?)
task completion statuses:
task what-do-I-need-to-do-with-it statuses:
- TODO
- READY ?or maybe ACTIONABLE?
- ?NOTREADY should this just be an isReady bool?
- WIP
- NOTSTARTED
- ?shouldnt these have similar substates as below WAIT, below?
- WAIT
- WAIT_FOR_DEPENDENCY
- WAIT_FOR_TIME
- WAIT_FOR_DELEGEE
- WAIT_FOR_REPLY
- WAIT_BLOCKED
task state-of-organizational-system statuses:
- TODO
- NEW/needs-triage/inbox
- IDEA
- READY
- WIP (active?)
- TODG
- DELEGATED
- CHECKING
- DONE
- SELECTED
- WAIT
- RELY? (subset of delegated?)
- SOMEDAY/MAYBE?
(um, no, e.g. CHECKING is a completion status, not an organizational system status)
does delegation go in what-do-I-need-to-do-with-it or state-of-organizational-system statuses?
- project status in terms of its status (the completion state of the task), vs in terms of what-do-I-need-to-do-with-it (vs in terms of state-of-organizational-system eg NEW/needs-triage/inbox)
task health statuses (and their colors): - healthy: green - minor_problems: yellow - major_problems: red - waiting/paused: blue
- 'Y: pending X' is a good way to say 'task Y hasn't started yet because it's waiting for X to complete first'
- mb extend char limit on statuses to 7 chars, then we can have PLANNED. Or do we want just PLAND?
old note: statuses can have substatuses (eg. todo can be 'todo' vs 'soon', done can be replaced by 'done' vs 'cancelled' vs 'hold', so in total we can have active/todo, active/soon, inactive/done, inactive/cancelled, inactive/hold)
ideas for smaller group of statuses:
- NEW
- IDEA
- TODO
- SOON
- BLOC
- WAIT
- WIP
- DONE
- HOLD
- NOPE
- NOPE
- CANCELLED/DISCARDED
- CANTREPRODUCE
- FAIL
- RELY
see gumroad roadmap: https://www.notion.so/Roadmap-ce2ad07c483046e7941227ad7810730d
mb "roadmap" instead of "planned"?
now ondeck soon anytime later someday
task completion status ideas: TODO/WIP/PAUSED/DONE TODO: NEW/IDEA/ROADMAP/PLANNED/READY/NEXT WIP: WIP/CHECKING/FINALIZING/REVIEWING/DONE
INACTIVE/ACTIVE/DONE
i guess WAIT is a what-do-I-need-to-do-with-it status, whereas HOLD is a task completion status
does the TRACKED/UNTRACKED/LATER/ZZZ stuff go here too? mb. that sounds like state-of-organizational-system stuff.
does WHEN stuff go here eg SOON, NEAR? No, scheduling is not status. Except that NEXT might be a state-of-organizational-system status. PENDING might be a state-of-organizational-system status, or a task completion status.
so here's some ideas: task completion statuses: TODO/DOING/DONE/HOLD TODO:IDEA/ROADMAP DOING:PLAN/STARTED/CHECK/FINAL DONE: DONE/DEAD
should PEND, BLOCK, HOLD be in task completion statuses? How about HALFway done?
i guess one way to think about is the task completion status is what a third party would want to see to see how a task is progressing. That would suggest, though, they you would want health stuff like BLOCK, HOLD, although from another perspective that seems ortho.
i guess another way to think about it is to write the agenda views that i want, and then redo the statuses to make them clearer.
task what-do-I-need-to-do-with-it statuses: READY/PEND/WAIT/BLOCK/TODG/DG
task state-of-organizational-system statuses: NEW/UNTRACKED/LATER/TRACKED/TODG/NEXT/RELY/REVIEW
or should DG be state-of-organizational-system statuses?
mb what-do-I-need-to-do-with-it statuses should just be READY/NOTREADY. Although maybe IDEA/ROADMAP is also a what-do-I-need-to-do-with-it concept.
and actually, DONE is a subtype of CLOSED (NIX is a potential sibling)
WAIT PAUSE PARK STALL STOP
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..
so mb WAIT vs DG are actually separate/ortho from each other
- still need to think a bit about what are the design goals for statuses
so maybe the three things are:
- completion
- 'stoplight health' is a subset of the WIP state here
- (how) is the task in motion (eg wait or not)
- what do you (and/or your organizational system, as a proxy for you) need to do about it (eg new, tracked, todg, dg, rely, untracked, stew)
- is there something in between IDEA and ROADMAP for things which are 'accepted' as tasks to complete, yet are not yet on the roadmap? Or maybe ROADMAP is that, and SCHED or PLAN is the next thing? That is to say, instead of SOMEDAY+MAYBEs, perhaps tasks start as MAYBEs and then transition to SOMEDAYs? Or, perhaps that's not quite it; perhaps something 'accepted' is still a maybe; it's accepted that we (probably) want it, but not that we'll actually get around to it. So maybe ACCEPTED or APPROVED is the best we can do? Maybe WANT (so IDEA, then WANT). Or maybe TODO (so IDEA, then TODO), altho mb that should be the superclass of subclasses like WANT.
should "snooze/defer" be a status?
my current setup has: NEW(n) IDEA(i) TODO(t) NEXT(x) PLAN(p) DO(d) BLOC(b) SET(s) SOON(o) GO(g) WIP(w) VERI(v)
LATER(l) MAYBE(m) RELY(r) DONE(e) HOLD(h) NOPE(-) CANT(c) OSCOPE(0) REF(r) |
other tags: WAIT STEW DG TODG WARN IMPORTANT URGENT QUICK LOOM DEC KEY MUST
some flaws with that:
- no READY
- something can be waiting on a dependency before it is started, or after (WAIT should be ortho)
- DELEG should be ortho (and included)
current ideas:
statuses before the
are open, after are closed. |
task completion: IDEA TODO WIP
DONE NIX |
substates of TODO task completion: ROADMAP PLAN READY NEXT substates of WIP task completion: GREEN YELLOW RED CHECK FINISH what you have to do: NEW TRACK REVIEW LATER RELY UNTRACK |
delegation: TODG DELEG FOLLOWUP RELY |
stop or go: WAIT PAUSE BLOCK DEP STEW HOLD |
what these mean: task completion: IDEA TODO WIP
task completion means how close the task is to being done
IDEA is an idea for a task that you haven't decided whether to do or not
TODO is a task that you want to do but haven't done yet
WIP is a task that is being working on
DONE is a task that has been completed
NIX is a task that has not been completed and is no longer planned to be done
substates of TODO task completion: ROADMAP BOOKED PLAN READY NEXT ROADMAP means that you are planning to do this task at some point BOOKED is a task that is not yet WIP but that we don't need to worry about finding time for because it has been scheduled/planned/delegated/booked PLAN means that you need to plan out how/when to do this READY means the task is ready to be done NEXT means that this task has been selected, possibly among some others, to be done "next", although multiple tasks can be in NEXT at once.
should BOOKED be a closed state? Alternately we need another distinction between TODOs that need attention, and BOOKED which does not. Should BOOKED be moved into 'what you have to do'?
we could extend the semantics of the
to mean any sort of distinction, then we get: |
substates of TODO task completion: ROADMAP PLAN READY NEXT
ROADMAP means that you are planning to do this task at some point
PLAN means that you need to plan out how/when to do this
READY means the task is ready to be done
NEXT means that this task has been selected, possibly among some others, to be done "next", although multiple tasks can be in NEXT at once.
BOOKED is a task that is not yet WIP but that we don't need to worry about finding time for because it has been scheduled/planned/delegated/bookedwhere the
means things that need attention, vs things that dont |
substates of WIP task completion: GREEN YELLOW RED CHECK FINISH GREEN means the task is coming along as planned YELLOW means there are some minor issues RED means there are major problems; the task requires major attention, and/or the task may not complete as planned and/or may be very late CHECK means that it is thought that the task is complete, but it still needs to be tested/double-checked/verified/approved by stakeholders FINISH means that the task is complete except for some finishing stuff (e.g. releasing to production, billing the client, etc)
delegation: TODG DELEG LOOK
TODG means you need to delegate this task
DELEG means the task has been delegated, but you still need to keep an eye on it
LOOK means the delegee says the task is done, and you need to take a look, and maybe send it on
RELY means the task has been delegated, and you can rely on the delegee to do it without you keeping an eye on it, unless something extraordinary happens (e.g. if the delegee quits)where the
means things that need attention, vs things that dont |
what you have to do: NEW TRACK DO STEW DEC FOLLOWUP REVIEW
NEW means the task is new to the system and may still need to be described/prioritized/categorized/scheduled/triaged
TRACK means you need to keep an eye on the task, and maybe plan when to do it
DO means you need to do the task
STEW means that you need to mull something over before continuing
DEC means that you need to decide something
FOLLOWUP means you need to follow up with someone
REVIEW means the task is closed except you should do a personal retrospective on it
LATER means that task is for a later phase of the project, and doesn't need to be tracked right now, although it probably will be tracked later
UNTRACK means that the task is not being 'tracked', for example, someday/maybe taskswhere the
means things that need attention, vs things that dont |
stop or go: GO STOP
GO means that the task can proceed (if someone does it)
STOP means the task is being stopped by something
HOLD means the task was put on hold, and does not need to be paid attention to unless and until is it taken off hold here, the
substatuses of stop: WAIT BLOCK
WAIT means the task is waiting for someone to get back to you, and may require followup
PAUSE means the task is waiting for time to pass or for some external event or condition to occur
BLOCK means the task has encountered some problem halting progress that needs attention
DEP means the task is waiting for another task to be completed before it progresses (maybe this should be PENDing?)where the
means things that need attention, vs things that dont (except to check if the condition is satisfied yet) |
now, which of these are mutually exclusive? If a bunch are mutually exclusive, then we can make them the orgmode 'TODO states'. Let's start with task completion. These can be combined with the substates of TODO and substates of WIP. They cannot be combined with delegation, because a task can be delegated before it is started or after. They probably can't be combined with 'what you have to do', b/c eg a task can be RED or GREEN, although here i'm not sure, and maybe RED YELLOW GREEN could be eliminated instead. I should think about this more.
STOP can't exactly be combined with task completion but it almost can; we just want to store the task status in a tag when it goes into STOP and then restore it later.
i think maybe we should split out the RED GREEN YELLOW.
maybe think about combining them like this: You sit down at your computer after going on vacation for two weeks, and need your memory refreshed about where things are at. As each task comes up, you think, "Oh yeah, that stupid thing. So where's this *#$*@! task at? And what do i need to do about it?". If any of these can answer those questions best, maybe they should be orgmode TODO states, even if they are logically ortho to task completion.
IDEA TODO WIP
DONE NIX? Yes, all of those. |
ROADMAP PLAN READY NEXT BOOKED? Yes, all of those. |
GREEN YELLOW RED CHECK FINISH? Yes, but we're taking out GREEN YELLOW RED, as per above. TODG DELEG LOOK RELY? Yes |
NEW TRACK DO STEW DEC FOLLOWUP REVIEW LATER UNTRACK? Some of them (NEW STEW DEC FOLLOWUP REVIEW); TRACK may not belong here, and maybe not LATER or UNTRACK either. |
GO STOP HOLD: HOLD and maybe STOP |
So, revised proposal:
completion: IDEA TODO WIP
DONE NIX |
TODO: ROADMAP PLAN READY NEXT BOOKED |
WIP: DO CHECK FINISH Delegation: TODG DELEG LOOK RELY |
What you have to do: NEW STEW DEC FOLLOWUP REVIEW Stopping: WAIT BLOCK PAUSE DEP HOLD |
That's 27 states! One too many for the 26 letters of the Latin alphabet! So maybe remove one of those. Maybe DO, b/c DO has the same semantics as its parent, WIP. So:
completion: IDEA TODO WIP
DONE NIX |
TODO: ROADMAP PLAN READY NEXT BOOKED |
WIP: CHECK FINISH Delegation: TODG DELEG LOOK RELY |
What you have to do: NEW STEW DEC FOLLOWUP REVIEW Stopping: WAIT BLOCK PAUSE DEP HOLD |
and ortho to all of those: TRACKED
mb change TODG to ASSIGN because none of the tohers start with A, but TODO starts with T.
alphabetically: ASSIGN BOOKED BLOCK CHECK DONE DEP DEC E FOLLOWUP FINISH deleG HOLD IDEA J K LOOK roadMap NEXT NEW NIX O PLAN PAUSE Q READY RELY STEW TODO U reView WIP WAIT X Y Z
OK rename DEP to reQuire. paUse. niX. relY. bOoked. DEC = STEW. NEXT can be/should be a tag rather than a status (TODO make NEXT a tag)
Now we have: alphabetically: ASSIGN BLOCK CHECK DONE E FINISH deleG HOLD IDEA J K LOOK roadMap New bOoked PLAN reQuire READY (could also be E) STEW TODO followUp reView WAIT WIP niX relY Z (pause)
so what should WIP be renamed/what letter should WIP be assigned to? Honestly PLAN may not need to be a status. We can always make separate tasks to plan things. So:
ASSIGN BLOCK CHECK DONE E FINISH deleG HOLD IDEA J K LOOK roadMap New bOoked wiP reQuire READY STEW TODO followUp reView WAIT niX relY Z (pause)
so right now we have: NEW(n) IDEA(i) TODO(t) WIP(p)
DONE(d) |
NIX(x) |
ASSIGN(a) DELEG(g) LOOK(l) RELY(y) WAIT(w) BLOCK(b) PAUSE(z) REQUIRE(q)HOLD(h) |
ROADMAP(m) READY(r) CHECK(c) FINISH(f) BOOKED(o) STEW(s) FOLLOWUP(u) REVIEW(v)
NEW conceptually belongs with STEW(s) FOLLOWUP(u) REVIEW(v) RELY BOOKED PAUSE REQUIRE REVIEW are open statuses that don't require attention
most common are probably: NEW(n) IDEA(i) TODO(t) WIP(p) WAIT(w) ASSIGN(a) DELEG(g)
DONE(d) NIX(x) |
maybe make those the first line (as long as there's a toplevel keybinding to go directly to DONE; otherwise probably want just NEW IDEA TODO DONE) (NEW is in here so that you can start on NEW and cycle to IDEA easily) (maybe dont have NIX there, i'm not sure)
and ortho to all of those: TRACKED
LATER UNTRACKED |
and ortho to all of those: NEXT
should we introduce STOP so that we have something like WAIT that generalizes WAIT BLOCK PAUSE REQUIRE that can go in the 'most common'?
and right now we have properties additional properties: completion, tracking, inMotion, isNext, health and computed properties attentionRequired, isOpen, isReady NEW STEW FOLLOWUP REVIEW can just be tags (or just todo states that act in place of tags). STEW FOLLOWUP REVIEW can be named something like 'microactions' or stdActions or something
maybe LATER is just a negative attentionRequired tag, rather than isTracking, and isTracking is a bool maybe we have: nexts \subseteq actionable \subseteq attentionReqd \subseteq tracked well not quite b/c you have have actionable untracked things -- but it's true that if something is both tracked and attentionReqd then there's something about that. Also the name attentionReqd is misleading because if it's low-priority and untracked you don't want to pay attention to it even when it is in an attentionReqd state.
someone else's: (setq org-todo-keywords (quote ((sequence "TODO(t)" "NEXT(n)" "
(sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE" "MEETING"))))
hmm mb get rid of the following as a separate data item (altho keep it conceptually): TRACKED
LATER UNTRACKED |
and instead compute that based on IDEA being UNTRACKED, LATER being a new status, and everything else being TRACKED? Well, that loses the ortho of having eg an untracked task be WIP. Hmm..
mb get rid of LOOK; just call it CHECK. How are we distinguishing b/t us checking and someone else checking? Maybe someone else checking is a WAIT?
why_nix: NOPE(-) CANT(c) WONT GAVEUP SKIP MISSED OSCOPE(0) DUP(r) CANCEL DELETE NOPE means someone decided they didn't want this to be done CANT means the task seems to not be feasible WONT means the task seems to contradict a design constraint or goal GAVEUP means we encountered difficulty and gave up SKIP means this task was skipped due to deprioritization MISSED means we missed our opportunity to do this OSCOPE means the task was decided to be out-of-scope DUP means the task has been merged into another CANCEL means that whoever desired/asked for the task changed their mind/unasked for it DELETE means that the task was deleted from this system for some reason
Internal planning as in how are we going to do this and X ternal planning as in how does this fit into the larger plan . Either of those can be in the plannING stage or plantnED.
booked description: You can have things scheduled for a certain day or you can just have things that are "Scheduled " Meaning that they are in some ordering or dependency chart or that someone else is responsible for them
One way to look at primary Task status is: whatever the kanban columns, should be?
(i mainly put requested not bc its a good state but bc it has a good abbrev: req)
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.
- 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
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.
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? b/c in GTD i think a person is often a context)
- what do i even want my system to look like? how would i do it on paper?
- some task status types are sort of like another form of WHEN enum (e.g. PLANNED/SOON/READY/LATER); in particular, i think this is another form of something similar to the whenSeq enum i described earlier
- yeah, there's some sort of pivot/relationship/homomorphism/transformation between task statuses, and some enums such as the WHEN enum. Maybe it's as simple as: statuses are just another enum, all the 'special' stuff about status is implemented as rules in the profile
- in that case there's a bit of 'computerized ontology' ( https://en.wikipedia.org/wiki/Ontology_(information_science) ) about these profiles, isn't there?
- hmm this leads into the config file format and programming language projects then...
- mb what you want in your config files is not a full programming language, but rather a real type system of some sort (so like that description logics etc research in computerized ontologies; see https://en.wikipedia.org/wiki/Ontology_language#Classification_by_structure_(logic_type) )
idea: since it's easy to go to the beginning or end of text files, use both ends. E.g. prioritized todos at the top, 'brainstorm' todos at the bottom. Or short term at the top, long term at the bottom. Or urgent at the bottom, important at the top. Or active todo at the top, waiting-on at the bottom. Or tasks at the top, notes at the bottom.
Features
readable plaintext exports
can export only a part/subset
also orgmode exports, todo.txt exports
chores
recurring 'chores'. These need to bubble up automatically.
custom colors
color tasks in various views according to custom filters, e.g. if the project and the task are important, then red, otherwise a different color per project
reviews
Reviews are recurring tasks (chores). Reviews are per-project, and different projects can have different review frequencies. Reviews inherit their project's importance.
Are the reviews in some sort of organiz/meta area, or are they in the project they refer to? I think they should be in the project they refer to. This assists in inheriting the project's importance.
You can also set reviews for Areas.
delegation
is my old system (DG, TOGD, @k, etc) good enuf or should i change it?
custom when types
in addition to time era and seq era, there can be other types of eras
potential features
- sequential vs parallel projects (sequential projects have an implicit dependency between each step)
next actions, stuck projects
Implementation architecture
- plaintext source of truth, but a in-memory db (to make preparation of things like org-mode's agenda views quick, easy, and customizable by end-users writing queries) (do we scan the plaintext from time to time to resync in case another process changed it?)
- i don't see a way to provide a custom function which is called when each candidate agenda item is visited and returns a bool to filter that item. This may make it hard to do some of my views. Should i add this functionality first, or do i not really need it yet? Let's try to proceed without it and see how far we get.
- if this is needed, it may be easier for later anyhow if i just go ahead and create my own agenda views replacement
- they do have a 'is this tag filtered' hook that seems useful tho
some links:
https://www.reddit.com/r/orgmode/comments/iw0web/orgsuperagenda_function_to_group_project_with_its/ summary: https://github.com/alphapapa/org-super-agenda groups stuff. Customize with auto-outline-path or auto-parent or auto-map.
https://github.com/alphapapa/org-super-agenda
https://orgmode.org/worg/doc.html
- can you have custom fields or even computed fields in agenda views? Yes, see org-agenda-prefix-format
"Each item occupies a single line. The line starts with a prefix that contains the category (see Categories) of the item and other important information. You can customize in which column tags are displayed through org-agenda-tags-column. You can also customize the prefix using the option org-agenda-prefix-format. This prefix is followed by a cleaned-up version of the outline headline associated with the item. " -- https://orgmode.org/manual/Presentation-and-Sorting.html
org-agenda-prefix-format to customize what is shown in each agenda line http://doc.endlessparentheses.com/Var/org-agenda-prefix-format.html org-agenda-hide-tags-regexp to not display certain tags org-agenda-remove-tags to hide all tags org-agenda-todo-keyword-format org-agenda-entry-text-exclude-regexps (setq org-agenda-entry-text-mode t) (setq org-agenda-entry-text-maxlines 5) org-agenda-entry-text-exclude-regexps
" (defun gg/entry-text-nix-empty-line () "Delete empty entry text lines in agenda" (goto-char (point-min)) (replace-regexp (concat "^ *" org-agenda-entry-text-leaders " *\n") ""))
(add-hook 'org-agenda-finalize-hook 'gg/entry-text-nix-empty-line) " -- https://emacs.stackexchange.com/questions/59546/getting-rid-of-plain-text-timestamp-entry-in-agenda-export
(http://sidebrain.sourceforge.net/ rec by a commentor in https://emacs.stackexchange.com/questions/51161/create-a-rabbit-hole-task-stack-that-can-be-pushed-popped )
" Try customizing org-agenda-prefix-format. This can be used to tweak how various kinds of items (including TODOs) are displayed in agenda views.
In particular, you can use %l in the todo format to prefix the item with a number of spaces corresponding to its level in the hierarchy." -- https://emacs.stackexchange.com/questions/5900/how-can-i-view-the-hierarchy-of-todo-keywords-in-org-agenda-mode
https://emacs.stackexchange.com/questions/14852/divider-lines-in-org-agenda
https://emacs.stackexchange.com/questions/5472/flexible-org-todo-dependencies
https://emacs.stackexchange.com/questions/tagged/org-agenda
org-agenda-filter-by-regexp https://orgmode.org/worg/doc.html read various hooks, search for org-agenda (so far i got about 25% through; to "org-agenda-list") https://karl-voit.at/2019/11/03/org-projects/ https://willschenk.com/articles/2021/sql_in_org_mode/ https://emacs.stackexchange.com/questions/63031/emacs-org-mode-custom-agenda-view-for-each-project https://emacs.stackexchange.com/questions/46882/custom-agenda-view-in-org-mode-grouping-per-month https://www.reddit.com/r/orgmode/comments/elacvo/orgsuperagenda_add_hierarchy_information_to/ https://orgmode.org/manual/Tag-Hierarchy.html https://orgmode.org/worg/org-glossary.html "Changing a TODO state can also trigger tag changes. See the docstring of the option org-todo-state-tags-triggers for details. " http://doc.norang.ca/org-mode.html https://orgmode.org/manual/index.html
could use CATEGORY to specify parent project
could mb implement my 'ortho' status facets using: https://orgmode.org/manual/Multiple-sets-in-one-file.html and org-todo-state-tags-triggers. That is, the TODO state is sort of a composite task status, and when you switch from one ortho dimension to another, org-todo-state-tags-triggers saves the value of the other one in a tag. The value in doing it this way rather than using separate properties/tags is:
- reuse orgmode's existing UI mechanism for TODO state cycling
- reuse orgmode's existing UI mechanism for TODO state display
- use the information stored in tags for more complex views and filtering
org-fast-tag-selection-include-todo
various things can filter/trigger by level, so it may be good to have a fixed number of levels for areas and maybe for projects. What do we do for an empty subarea? Or do we just make the user make up areas for that? Or is the convention that it's the same name as the parent in that case (this could also be the home of catchall'd tasks that are in a parent area but not in any of its subareas)? Or could the convention be that it's the empty string in that case (would make area::subarea formatting simpler: "area::" for the catchall subarea)?
https://orgmode.org/manual/Stuck-projects.html
can agenda views recognize negation of a tag? Yes; using '!', see https://orgmode.org/manual/Matching-tags-and-properties.html. This could make tags triggered onto todo state change easier; otherwise for each ortho set of tax we would have needed to introduce a default, for instance not NOTDELEGATED
principle: want to be able to infer default ortho properties if they are not given. So maybe untracked should be a tag, and idea
later | untracked means untracked, otherwise the default is tracked |
- is there a hook for when any tag or property changes, or only when TODO status changes? Yes, all of them are possible:
- when property changes: org-property-changed-functions (called from org-entry-put)
- when tags change, i think: org-after-tags-change-hook (called from org-set-tags)
- there's a more general org-trigger-hook, but it seems to be only for todo status right now. There's also org-after-todo-state-change-hook, which is run slightly earlier -- both are run from org-todo ("Change the TODO state of an item.")
https://orgmode.org/worg/org-tutorials/org-custom-agenda-commands.html org-agenda-entry-types
http://doc.norang.ca/org-mode.html shows how to define 'projects' as any item with subtasks, and then find stuck projects (projects without a NEXT action): http://doc.norang.ca/org-mode.html section http://doc.norang.ca/org-mode.html#TodoKeywordProjectTaskStates section 14.2 Project definition and finding stuck projects
UI
UI TODO
main screen: modular query spacebar to edit task (without leaving screen) enter to:
- add new task?
- descend into subtasks (eg if the current item is a project)?
- select item?
- change status?
keys i toggles the IMPORTANCE>=1 seach filter on or off I sets a custom IMPORTANCE threshold
edit task mode: choices of key assignments (are consistent with the idea of / reflect the semantics of) keys in modular agenda view
i toggles the importance of the task between 0 and 1 I sets the importance to a custom number esc goes back to modular query mode
new task mode is just edit task mode
if the user doesn't enter a key for awhile, the key hints popup. ? goes to the key assignment help mode. F1 is like 'less' viewing the plaintext manual.
Some of the function keys switch to various preset queries.
On the sidebar is a few preset queries, and starred items, and a project browser.
keybindings: using cokemak layout, here's what we have to work with: (omitting keys like tab, backspace, enter, home, shift, which cannot easily be typed/shown as a single character):
`1234567890-= qwfpgjluy;[]\ arstdhneio' zxcvbkm,./
the home row is:
arst d h neio '
so the most common stuff should go there. My email keybindings work pretty well:
a,A: todo-, todo r: reply, sort reverse s: low, mbox t: up, first
d: archive (dont delete the message, but dont tag it either, and remove from inbox), save (like archive, but also tags with 'save' h: important toggle, flag toggle
n: down, last e: delete, mark with the 'deleted' tag but don't actually delete (note: i dont use this one much) i: fyi, toread (toread means an important fyi) o: wait, ref
',": ctx, custom edit labels
tab: next-new-then-unread enter: display-message space: display-message
so can i be inspired by those to get some ideas for the etd home row?
in email, the most important (non-motion/command/special) key is delete. What is that for tasks? Maybe importance, or maybe when, or maybe todo status change.
note that most task views (a) group by project (or whatever else the user specifies), and (b) preserve task (and section and note) ordering unless the user specifies something else
predefined enums such as statuses are at most 8 characters, and the UI assumes that custom variants are also at most 8 characters (when setting column lengths, etc)
2D grid to cycle through substates
it will be less annoying if the keyboard hints box at the bottom of the UI is permanent rather than appearing after a few seconds of inactivity
The problem with having too many statuses is that in the UI it's too hard to specify one or to cycle through them. This can be ameliorated by per-project choice of status via "project type". Project type could also select whether when era is time-based or sequence / sprint-based. Also these choices could be made at the level of any item for its sub items rather than at the project level; or alternately, an items "project" is its closest ancestor of type project whether that is a project sub project or sub sub project etc.
some paper planners have an "important dates" page -- this is just part of the overview
Common symbols
W: firm when w: soft when I: important (importance >=1) i: importance <1
Keyboard keys
- consider using something that corresponds to my email custom keyboard layout
- quick UI to 'snooze' tasks
- / for search
- enter or spacebar to create a new item
- spacebar or enter to edit item
- p for project
- x for select
Displays
- show filtered views that only show one project
- list tasks under project headings in cross-project views
Views (modes)
some modes we have: agenda view/modular query, edit item, help
agenta view
shows one line per item and no empty lines in between
Expanded agenda view
shows three lines instead of one and empty lines in between items?
Timeline view
Calendar view
can be per-project, that is, can see each project's 'Calendar'
Kanban view
- sprint planning for the 'tracked' projects: each project has a kanban with columns like 'ready', 'wip', 'done' (and maybe more). These correspond to statuses. The columns included in the kanban can be customized (per-project?): a column can be added for any status (and recall that we have hierarchical statuses, and recall that statuses are a form of types of tasks, so by creating a task status with two "subtype"s, you can set a kanban column to the parent task status and see all tasks in the project whose status field is set to either the parent status, or either child status) or for any boolean expression on tags (and statuses are a type of tag).
Overview views
you can view all tasks by month; but you can also view the month overview, which is a different thing
an overview of an era (are there other kinds of overviews, not counting the ordinary task views/queries such as all important+urgent or flagged or favorited, etc?) includes those tasks which are marked as overview for this area
What else do era overview screens include (are tasks which are both important/urgent at the level of the era included? What about tasks which are both important/urgent in suberas, eg imp urg tasks (the 'now' era) when viewing the month era)?
the PARA system uses the P->A->R->A not just as types, but as levels of overview-ness
in an era overview you can see which tasks will be urgent in that era
older note:
- should we have different "heights" from which to view time? That is should we have characterization of upcoming month in a way different than the union of everything in all the days of that month? If so, do we have events that appear only at the month level, and do we also have some daily events that are promoted to appear at the month level?
Edit item screen
edit item screen starts in a text box editing the item text but other fields are also displayed and you can tab over to them? Or maybe hit escape and then use standard keys (like d for deadline) to access them. In fact maybe editing starts without editing the text so that you can use those keys
Flags and stars
sIf imp and urg and priority are relative to each project, is there any way for a user to force a task to be marked something like 'important' in the global views, that is, UI views showing tasks from all projects? Yes, there is a "flag" functionality, and flagging is global. There is also a 'star' functionality which is adds a task to a 'favorite' list (which is then shown in various parts of the UI, eg the main sidebar; but 'favorites' have relevance to the data ontology beyond just being a UI element (later: okay what is that relevance? my they show up in overviews?)).
Ref autonumbering
Can automatically put hierarchical autonumbering in the 'ref' field, eg. 1.3.11.4, but then later 'freeze' the existing numbers -- this allows you to eg draft a requirements document to give to a contractor, and then after that document is shared with a contractor, freeze the numbering and use the numbers as perma-IDs.
Queries
Preset query screens
- updated in last week
- newly assigned/requested to me
- newly assigned/requested by me
- waiting-for
- important and urgent
- week view
- month view
- next few days/now view
- new/inbox
show important/urgent tasks in any chosen era
Modular queries
i vs I: I means filter for importance >=1 w vs W: W means filter for firm when
various keys for 'when' in various eras
- some fancy query modules:
- only show the first available item in each project
- show all available items (available = not blocked, deferred, or on hold)
- show all remaining (ie not completed) items
- all
Fully custom queries
Use some sort of query language
allow saving queries
Menu bar
Function keys
F1: help F2: F3: F4: F5: F6: F7: F8: F9: F10: F11: F12:
Misc UI notes
- if you dont annotate orgmode items with a task status, they are treated like notes, not todos. But in my tool i think we want things to be todos by default, and notes only if they say NOTE or something like that
- vim-like 'nouns' and 'verbs' such as 'x' for 'task status done'; in some contexts x marks a task as done, in others it queries for done tasks
- want agenda views to show tasks under, and grouped by, their projects (headings), and those in turn under their areas. Also need to be able to easily restrict the view to one area or project.
- (another note saying the same as previous) should be able to list tasks by project, that is, within various lists, display the projects as headings under which go their tasks
- so when looking at a 'when', e.g. 'this week', projects should appear under area headings. But when looking at an area, projects should appear under (usually multiple?) 'when' headings.
- want (not yet active) subtasks ("actions") in agenda to not show by default, but you can expand the main task to show them
- action to easily convert task to project
- should be able to order stuff (put items in an ordered list and have that ordering be remembered)
- want to be able to select many tasks and then assign a due date to many of them at once
- UI must be discoverable, esp things you immediately need after sitting down at system after a long break: how to set dates, how to mark an item as done, etc
- keyboard shortcuts should be the same in docs and in agenda view
- .org document editing shows the (non-task) notes by default a lot of the time, which was too much detail for most purposes. Need to avoid that.
- don't have too many keystrokes to do common things
- don't have too many keystrokes to pluck things into the current epoch (set When date)
- quick capture hotkey
- list of all active projects, including ones under the null area, which should be listed at the top
- easy way to reorder projects
- custom enum sequences; for: electric/hvac/plumbing/etc, additional 'when' types. Can show tasks under section headings of a custom enum in addition to the custom section headings
- discoverability stuff in the UI: keyboard shortcuts screen (?), manual/help (F1), menu bar (under hamburger menu in mobile), status bar, sidebar, tooltips, function keys
- orgmode-like cycle-between-task-statuses can be applied to any enum
UI hard / for later
stuff that is probably hard to do, so dont bother for now
- agenda views should not be slow
- drag UI to put something under something else
- email integration: email to etd and then when you get to the task, it calls up the email.
- calendar integration ('events' live on calendar, 'deadlines' live here but optionally can be copied to calendar)
- multiuser stuff: assignment (or request and accept/reject), comments, mentions
- group access privs: read-only, read and comment, full editing, owner/admin (can add/remove others' permissions)
- groups can be given permissions on projects (as if the team were a member; this permission is then the permission of all members on the team, unless overridden by a specific permission grant)
- ('newly assigned to you' status)
- file attachments
generally, we're going to focus on what we can easily on top of orgmode setup, without too much programming. Mayyybe later we can do more, but don't count on it. It's useful to design the ideal system
Misc notes
- some theoretical advantages of a computerized system over paper: full-text search; easy to move things around; instead of having separate sections where you list tasks with certain characteristics, you can include those characteristics in the task item core data structure and present different views of this database as list of tasks meeting certain criteria (database queries)
Toreads