notes-organization-organizEtdDesign

Difference between revision 6 and current revision

No diff available.

Design todos

also: check out https://develop.spacemacs.org/layers/+emacs/org/README.html#org-agenda-transient-state and also the leader key stuff at the top of https://develop.spacemacs.org/layers/+emacs/org/README.html#key-bindings-1 which i seem to have made unavailable somehow in my setup because SPC is bound to org-agenda-show-and-scroll-up and BACKSPACE to org-agenda-show-scroll-down and check out https://orgmode.org/manual/Agenda-Commands.html

list of buckets giving reasons to especially care about a task

place tasks that you especially need to remember (important or urgent or soon)) into a small number of buckets, maybe 12. Buckets are things like 'important and urgent'; they represent the reason that you need to especially remember this task. Whenever you encounter a task that you are afraid to delete from its original location (eg email) and throw into the task manager, maybe you need to add a bucket to this list.

Buckets so far:

and examples:

Feature summary list

Non-standard task attributes

Eras of time (timeEra)

Time eras are represented as integers using the following enumeration/convention:

1=today 2=tomorrow 3=next_few_days 4=week 5=next_few_weeks 6=month 7=quarter 8=year 9=someday 0=nil. In the UI the "0" key is used to assign this.

A floating point number in between two eras is treated as falling in the next higher era (eg 1.5 is in the 'tomorrow' era)

Most eras are subsets of each other: (today or tomorrow) \subseteq few_days \subseteq week \subseteq few_weeks \subseteq month \subseteq quarter \subseteq year \subseteq forever

taskType?

0=nil/ordinary 1=tosay 2=todg 3=chore 4=quick/anytime 5=errand 6=call/mtng 7=physical 8=atcomputer 9=meta

Questions

Questions about delegation

Questions about priorites

Questions about WHEN/eras

Questions about other planning attributes

Questions about statuses

Questions about implementation

Questions misc

Statuses

ok, i'm a little lost there. What do i need the statuses to do, and what was wrong with the way i was doing them before? what do i need them to do:

what was wrong:

one design principal is to minimize the number of things in various stages of the system. This is the same principal as:

for each state, the design justification: NEW: partially formed tasks need to be marked as such, because the propositions 'declared' by the states of some of their fields may be incorrect; one consequence of this is that they need to be kept out of the other states otherwise they may erroneously appear overly highlighted in various views IDEA: keep things out of TRACK ROAPMAP: keep things out of READY SOON: trigger things dependent on this being in SOON (eg tasks involved in getting-ready-for the task in SOON) -- i feel like something that needs to trigger dependencies should be an actual state, so that we don't need to include the concept of tags in our model of dependencies (but we can include statuses); except for the need to trigger dependencies, this would just be a tag, a substate of ROADMAP READY: this is sort of the primal TODO; some superset of this is needed to fulfill the feature requirement of "look at the system and get a list of things i should consider doing now" (especially when refined by the 'actionable' predicate); by keeping ROADMAP (and SOON) out of this, we reduce the number of items shown in here DO: we can minimize the number of tasks in TRACK by prioritizing finishing things that we have already started (like DO) over things we haven't (like READY) note: is this really true though? does prioritizing a long task in DO over a short task in READY help this? i would think not really... CHECK: same justification as DO; by prioritizing these over DO, we can minimize the number of tasks in TRACK FINAL: same justification as DO and CHECK WAIT: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them DELEG: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them. This is different from WAIT in terms of task completion status, because here the task is not actually stopped. BOOKED: keep tasks from appearing in non-review views of TRACK (needsYou) when we can't/won't do anything about them. This is different from WAIT in terms of task completion status, because here the task is not actually stopped. Why is it not just a tag? Because it applies to both SOON and ROADMAP HOLD: keep things out of TRACK and out of IDEA and out of OPEN CUT, DONE: to keep things out of the system, we need at least one terminal state, it's convenient to indicate whether the task was completed or not

TODO:

Perspectives

need places to put:

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:

to put another way, systems for:

i might divide this into:

"someday" todos "anytime" todos

Use cases

some key activities include:

Need solution for

Situations and their solutions

Approaches

stuff to think about

some of my immediate use cases include:

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.