notes-organization-old-organizEtdDesignOld asof 220115

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)

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

IDEA: not startedTODO: not startedWIP: 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 startedREADY: not started, actionable, tracked? (NEXT?: not started, actionable, tracked?) CHECK?: started, actionable, tracked BOOKED: not started

started (any open), any activity, actionable, tracked

started (any open), go, actionable?, untracked

started (any open), any activity (eg dep, ready), actionable?, tracked

started (any open), not actionable? (not READY), tracked? later?

started (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

roadmap, must

• 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?