notes-organization-old-organizEtdDesignOld1

---

Feature summary list

some todos for this project:

simplify imp etc to just:

maybe orgmode, but with a simpler plaintext format, and with internal functions using a database that is kept synchronized with the open buffer (that last bit (the synchronization) sounds difficult, but i think it's worth it to allow the user to do their own queries -- however don't use SQL, SQL is too complicated, and also it requires that you either ((choose a safe client), or (really know what you are doing)) in order to avoid security issues)

the agenda definitions are where you could really use a query language. And also allowing the user to do an interactive query over tasks to interactively build an agenda view (this is mainly to allow the user to do transient queries, but they can also save the query they interactively built if they want). And of course, as a side benefit, they simplify the rest of the code (at the cost of the synchronization complexity).

ok so something i need to think about:

(note: not specific to this project, but recall that one way of using the words "complication" and "complexity" is that complication is mere quantitative increase in informational clutter, whereas complexity is something that requires qualitatively deeper thought in order to understand it/work with it/solve its problems. In a design context, some amount of complexity is inherent in the problem; the inherent problem complexity is inescapable so one should not try to find a solution that isn't itself complex enough to address the inherent problem complexity. This is not to say that one should attempt to estimate the complexity of the inherent problem complexity, and estimate the complexity of the solution, and try to match them (that would be cool, and works sometimes in math, but this domain has not been sufficiently formalized to allow the application of those kinds of methods); rather, it is saying that although unnecessary complexity is often bad, it should be forgiven if the solution complexity is necessary to deal with the inherent problem complexity. Aside: there is a debate about the treatment of solution complexity beyond what is necessary. Some say that any complexity beyond what is necessary is bad. Others say that in some circumstances, some unnecessary complexity is justified in order to buy expressive power, even though in other situations unnecessary complexity is all bad (a criticism of this approach is that it seems to be hard to tell in which circumstances expressive power can justify complexity). I am on the side that expressive power can sometimes justify complexity; but yes, some amount of judgement/taste is involved in order to choose when.)

---

tasks can stand in subtask/supertask relationships tasks can be members of projects (and multiple projects, which means you can have cross-project projects, or 'epics') is a project different from a supertask? not really.. project can have status, etc. Just call it a task. tasks can have effort estimates due dates can be hard or soft custom fields can be associated with tasks; can include enums, dates, strings, floats, integers, what else? tasks can have vote counts tasks can be assigned to people people can subscribe to tasks tasks can mention people tasks can have tags tasks can link to hyperlinks tasks can have file attachments tasks can have attached comments projects can have members project members can have permissions: read-only, read and comment, full editing, owner/admin (can add/remove others' permissions) project members can have custom roles (strings/enums) members can be grouped into teams teams 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) tasks and projects can be starred tasks have a status at least todo/done 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) people are notified when tasks are assigned to them tasks can have dependencies (blocked by, blocking) tasks can have data private to each person (e.g. private priorities and statuses, eg today/upcoming/later, 'new/unseen', 'newly assigned to you', etc)

... so basically i think orgmode does all this except maybe for the ordered queue

---

---

high-level motivations for organizational systems:

Statechart diagram todo

Statechart diagram what i've drawn so far

Statechart diagram notes

Statechart diagram questions

DELEG ..., where the unnamed 3rd region (possibly recursively) contains ROADMAP

i think i like this pic so far (except, as i said, i would put WAIT on the rightmost side within TODO, rather than the leftmost). I need to examine it more critically, though, to make sure it can consistently represent what i need it to.

so how about this:

WAIT
DELEG

i feel like the stuff under DOING is wrong, and maybe the transition TODO->DOING also. What i'm trying to do is (a) have TODO->DO->CHECK->FINISH->DONE, (b) also have TODO->DOING->DONE, while not having TODO->DO->FINISH or TODO->DO->DONE or TODO->CHECK or TODO->FINISH or TODO->DONE. I think the above contains TODO->CHECK and TODO->FINISH, so it's not quite right yet. Maybe try:

WAIT
DELEG

does this satisfy the desiderata above?: - the following paths must be present: - TODO->DO->CHECK->FINISH->DONE: true - TODO->DOING->DONE : true (because this is a zoom-out of TODO->DO->CHECK->FINISH->DONE, so the presence of that path implies the presence of this one) - the following paths must be absent: - TODO->DO->FINISH : true - TODO->DO->DONE : true - TODO->CHECK : true - TODO->FINISH : true - TODO->DONE : true yes, it does.

So, currently, my best guess so far is:

WAIT
DELEG

see pic (220117_guess3.jpg)

where the states OPEN, CLOSE, TRACK are not directly visible to the user, at least not in most places. So that leaves 12 user-visible states.

Note that ROADMAP is left out here. Is that what i want? Or do i want to create various substates inside TODO, including ROADMAP, and make ROADMAP the entry state in TODO? Recall that the motivation of ROADMAP is to save TODO to be a superstate for various substates that are presumably moved through in a linear manner. I'm not quite sure how to do that without making a committment to what these substates are, though, which is one reason that I left TODO empty for now.

Some remaining questions: what about: - readiness the concept (or alternately, a READY state) - definiteness/committment/toconsider - 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?) - needs attention? - question marks

elsewhere, about my old set of states proposal, i wrote: " if you look at all those states, here are the ones that are very common: new idea todo wip check finish done nix wait

and here are the others: assign deleg look rely block pause require hold roadmap ready booked stew followup review "

so the current proposal would have all of the common states (albeit with some different names), and out of the others, only deleg, hold. out of the others, assign, look would be substates of DELEG, and block, pause, require, followup would be substates of WAIT, and roapmap, ready, booked would be substates of TODO, and review would be a substate of doing in between FINISH and DONE. That leaves only rely, stew as possibly having more complex semantics.

actually i think the orthogonal regions don't change the semantics much unless they have multiple states in them. So we do need at least two WAIT states and at least two DELEG states. Let's call them STOP,GO and NOTDELEG, DELEG

maybe HOLD should be promoted to a third alternative to OPEN, CLOSE. In fact, WAIT could be that, if we're willing to forget of task status when we enter WAIT.

CHECK and FINISH still seem a little unnecessary. So maybe to start with, remove these. To start with (and maybe later, too), WAIT and DELEGATE are boolean properties. Remove HOLD; WAIT is good enough for that. A task is called "active" iff: (it is in TRACKED) AND (isWaiting is false) AND (isDelegated is false). I guess instead of isWaiting, isDelegated, we can use tags WAIT, DELEG

also, any state in OPEN can't transition to any state in CLOSE; DONE can only be reached via DOING. So it's just CANCEL that can happen anytime.

( is there a better word for 'active'? I'm using it for (isActionable OR canUseAttention); if we later add more states under TODO, some of them may not be "actionable"

what i'm getting at is tasks which need your personal attention, either to plan to do them or to do them. What we are really saying is that these are tasks that are waiting-for YOU! "need" sounds more like could/would/should/must. "personal" sounds like un-delegated. needsAttention sounds more like FLAG. "the ball is in your court" is too long and metaphorical, as is anything having to do with it being your turn (YOURTURN). Maybe FORYOU? NEEDSYOU?

maybe TRACK should be renamed to 'active'. And then we can use 'track' for what i called 'active', above. But it sounds weird to call a task which is in WAIT "active". And 'track' doesn't seem to imply that personal attention is needed. In fact, in a sense, tasks which need your attention are the definition of passive; they won't do anything unless you do something to push them.

so far i'm thinking isForYou, although i don't love it. )

so i think our current statechart is:

WAIT (tag)
DELEG (tag)

needsYou := TRACK and !WAIT and !DELEG

here there are 6 user-visible states plus WAIT, DELEG, so 8 user-visible "things". SOON can also be a tag.

If we wanted to get more complicated, we could do:

WAIT
DELEG

actionable := (READY or DOING) and !WAIT and !DELEG needsYou := actionable OR ROADMAP (should SOON be needsYou? in which case only BOOKED is NOT needsYou within TODO) (mb BOOKED is an ortho) (mb NEEDSYOU is an ortho)

this introduces 7 additional states. I'm thinking it may be too complicated for now; because without an explanation it's hard to guess the semantics of ROADMAP, BOOKED, SOON (although, CHECK and FINISH are fine; but they seem unbalanced without more stuff in TODO, since that is where we really need more structure). Could also have a FOLLOWUP state which doesn't easily fit on the diagram; it is in both WAIT and DELEG (that is, there is WAIT_FOLLOWUP and DELEG_FOLLOWUP). The point of expanding TODO is to distinguish actionable TODOs (READY) from non-actionable ones, and to distinguish non-actionable needsYou TODOs (ROADMAP) from non-actionable TODOs that don't need you (BOOKED and SOON), and to distinguish things that are happening SOON from things that are not. Also, i'm not even sure what the point is of having ROADMAP be a non-actionable needsYou. These correspond to pietri's whiteboard as follows: IDEA -> deep backlog, TODO -> near backlog, ROADMAP -> do after that, SOON -> do soon, READY -> next. Also, my WAIT -> his HOLD, my DO -> his WORKING, my CHECK to his TO REVIEW. Hmm the fact that he has these does make me think they are more likely to be worth the complication, maybe we should have them. He doesn't have BOOKED but i kind of like that because it allows me to distinguish something that needs to be planned (NEEDSYOU) for from something that is already planned for. Also, i'm not sure if there should be additional state transitions within TODO to skip over some of those stages.

here's how it looks with BOOKED as an ortho:

BOOKED
WAIT
DELEG

actionable := (READY or WIP) and !WAIT and !DELEG needsYou := actionable or (TODO and !BOOKED)

so here we have 10 user-visible states (new idea roadmap soon ready do check finish cancel done), and 3 user-visible tags (wait deleg booked). Behind the scenes, we have 7 more concepts (open close track todo wip actionable needsYou). So 13 user-visible things and 20 things total.

should BOOKED be ortho with READY, also?

note: the naming convention is broken with BOOKED but i think just saying BOOK would be confusing, and i cant think of a better word.

i kind of like this one.

at this point we can give an explanation of the semantics of each state, and why it's useful:

NOTE: the state transitions above describe the 'ideal' path of a task through the workflow, but in reality, the software lets you change the status arbitrarily.

NEW: just entered into the system. May need to have stuff like importance, category set. IDEA: a potential future task; a someday/maybe. It has not yet been decided whether we are going to do the task in the forseeable future. We want to keep this task in the system, but we don't need to track it.

TODO states: things that we are planning to ROADMAP: a task that we are planning to do in the forseeable future. We need to regularly review this task to make sure it moves forward. SOON: similar to ROADMAP, but also indicates that this task will be done 'soon'. Perhaps you have some other things that you need to do to get ready for the task; now is the time to start doing those. READY: a task that is ready to be done now

WIP states: (W.I.P. = Work In Progress) things that are being worked on DO: a task that is being done CHECK: checking over/verifying/testing/validating the work that was done. This can be something we are doing, or it could be that we are waiting for someone else to look it over and approve it. FINISH: whatever needs to be done after the task has been checked and passed. For example, deploying software after it has been tested; billing clients after the client has signed off on a completed project; cleaning up a worksite; etc.

CLOSE states: CANCEL: the task wasn't completed and we aren't thinking about doing it DONE: the task was completed

(about 13 user-visible states+groups of states there, plus 3 tags below = 16 things for the user to understand well)

groupings of states: OPEN/CLOSE: OPEN states are things that we are thinking about doing. CLOSE are the others (CANCEL and DONE are CLOSE, and everything else is OPEN). TRACK: tasks that we plan to complete (and so they need to be kept track of). TODO or WIP

tags: BOOKED: this can apply to ROADMAP and SOON. It means that there is a schedule or plan to start doing this task at some point, so it is not in need of scheduling. WAIT: this can apply to anything in TRACK. It means that the task is waiting before it can proceed, so there's nothing you can do to push it forward now (except perhaps followup with someone else if the task is waiting for them to do something). Some reasons that a task may be WAIT are that it may: have been placed 'on hold' by you; be waiting-for someone else to do something; be dependent on some other task and waiting-for that task to complete; be waiting for time to pass or for some external event to occur. DELEG: this can apply to anything in TRACK. It means that you have delegated/assigned/hired someone else to do this task, so there's nothing you can do to push it forward now (except perhaps followup with the delegee)

predicates: actionable: Things that you might work on now. (READY or WIP) and !WAIT and !DELEG needsYou: Things that need you to do something (either do the task, or plan for it to be done/schedule it/push forward its planning) . actionable or (TODO and !BOOKED)

some other potential tags: IMP URG FLAG TROUBLE QUESTION MAYBE

---

old design todos

Core data structures

Area data structure

Item data structure

TaskTemplate (subclass of Item)

RecurringTask (subclass of TaskTemplate)

Task data structure (subclass of TaskTemplate)

Computed properties:

NOTE:

Note data structure (subclass of Item)

Heading data structure

Computed property:

Person

User

Group

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

---

Questions

---

better names for ROADMAP? intent? agenda? plan? chosen? will? selected? scheme? track? plot? intent, will, chosen dont capture that not only do we intend to do this, we are tracking to do this in the forseeable future -- it's not just a SOMEDAY selected is too generic and too long agenda is good but maybe too overloaded. plan is too overloaded, b/c (a) it sounds like BOOKED (b) maybe this task needs to be planned out track is something that we do to other states too, so that would be confusing scheme and plot would probably confuse ppl remaining: roadmap agenda onplan inplan so far, ROADMAP is still best

maybe CUT instead of CANCEL

statuses

task completion statuses:

task what-do-I-need-to-do-with-it statuses:

task state-of-organizational-system statuses:

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

task health statuses (and their colors): - healthy: green - minor_problems: yellow - major_problems: red - waiting/paused: blue

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:

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

so mb WAIT vs DG are actually separate/ortho from each other

so maybe the three things are:

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)

other tags: WAIT STEW DG TODG WARN IMPORTANT URGENT QUICK LOOM DEC KEY MUST
LATER(l) MAYBE(m) RELY(r) DONE(e) HOLD(h) NOPE(-) CANT(c) OSCOPE(0) REF(r)

some flaws with that:

current ideas:

statuses before the

are open, after are closed.

task completion: IDEA TODO WIP

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 delegation: TODG DELEG FOLLOWUP stop or go: WAIT PAUSE BLOCK DEP STEW
DONE NIX
LATER RELY UNTRACK
RELY
HOLD

what these mean: task completion: IDEA TODO WIP

DONE NIX
  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

BOOKED
  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

RELY
  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

LATER UNTRACK
  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

HOLD
  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
still means open/closed

substatuses of stop: WAIT BLOCK

PAUSE DEP
  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

ROADMAP PLAN READY NEXT GREEN YELLOW RED CHECK FINISH? Yes, but we're taking out GREEN YELLOW RED, as per above. TODG DELEG LOOK NEW TRACK DO STEW DEC FOLLOWUP REVIEW GO STOP
DONE NIX? Yes, all of those.
BOOKED? Yes, all of those.
RELY? Yes
LATER UNTRACK? Some of them (NEW STEW DEC FOLLOWUP REVIEW); TRACK may not belong here, and maybe not LATER or UNTRACK either.
HOLD: HOLD and maybe STOP

So, revised proposal:

completion: IDEA TODO WIP

TODO: ROADMAP PLAN READY NEXT WIP: DO CHECK FINISH Delegation: TODG DELEG LOOK What you have to do: NEW STEW DEC FOLLOWUP REVIEW Stopping: WAIT BLOCK
DONE NIX
BOOKED
RELY
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

TODO: ROADMAP PLAN READY NEXT WIP: CHECK FINISH Delegation: TODG DELEG LOOK What you have to do: NEW STEW DEC FOLLOWUP REVIEW Stopping: WAIT BLOCK
DONE NIX
BOOKED
RELY
PAUSE DEP HOLD

and ortho to all of those: TRACKED

LATER UNTRACKED

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)

ASSIGN(a) DELEG(g) LOOK(l) RELY(y) WAIT(w) BLOCK(b) PAUSE(z) REQUIRE(q)ROADMAP(m) READY(r) CHECK(c) FINISH(f) BOOKED(o) STEW(s) FOLLOWUP(u) REVIEW(v)
DONE(d)
NIX(x)
HOLD(h)

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)

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)
DONE(d) NIX(x)

and ortho to all of those: TRACKED

and ortho to all of those: NEXT
LATER UNTRACKED

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

" "DONE(d)")
              (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

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..
LATER UNTRACKED

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 subtypes: CANTREPRODUCE WORKSFORME 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 (mb MOVED would be better; mozilla has both DUP and MOVED) 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 INVALID

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)

roadmap, must
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)
    - even bulletjournals have todo statuses vs 'signifiers'
  - 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?
  - mb saying 'trinary' is a little overly prescriptive/numerology-ical. different dims can have different numbers of enums. Also, 4 might not be a hard rule either.

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 also, a lot of things are unspecified w/r/t one or more dims, so an exhaustive enumeration like this may not be the right notation; it's too cluttered; so mb just mention the ones that are constrained w/r/t some dim

if you look at all those states, here are the ones that are very common: new idea todo wip check finish done nix wait

and here are the others: assign deleg look rely block pause require hold roadmap ready booked stew followup review

READY can mean two things:

BLOCKED can mean two things:

in one sense, it doesn't matter much to the task manager whether potential tasks have been 'accepted'/approved yet (eg. toconsider/explore have not been accepted yet), vs when they have (eg ROADMAP; backlog::icechest vs backlog::backlog); in either case, the task needs to be shown to the user for deciding/planning (perhaps at the proper time, after some dependencies have been resolved). On the other hand, it's something that the user probably wants to see, so it should be included. So, should we include stuff like COULD/WANT

WOULD/SHOULD/WILL/MUST or not?

the orthoness of WAIT and DELEG is making me question trying to include all of this into a single status again

BOOKED
WAIT
DELEG

actionable := (READY or WIP) and !WAIT and !DELEG needsYou := actionable or (TODO and !BOOKED)

so here we have 10 user-visible states (new idea roadmap soon ready do check finish cancel done), and 3 user-visible tags (wait deleg booked). Behind the scenes, we have 7 more concepts (open close track todo wip actionable needsYou). So 13 user-visible things and 20 things total.

should BOOKED be ortho with READY, also?

note: the naming convention is broken with BOOKED but i think just saying BOOK would be confusing, and i cant think of a better word.

i kind of like this one.

at this point we can give an explanation of the semantics of each state, and why it's useful:

NOTE: the state transitions above describe the 'ideal' path of a task through the workflow, but in reality, the software lets you change the status arbitrarily.

NEW: just entered into the system. May need to have stuff like importance, category set. IDEA: a potential future task; a someday/maybe. It has not yet been decided whether we are going to do the task in the forseeable future. We want to keep this task in the system, but we don't need to track it.

TODO states: things that we are planning to ROADMAP: a task that we are planning to do in the forseeable future. We need to regularly review this task to make sure it moves forward. SOON: similar to ROADMAP, but also indicates that this task will be done 'soon'. Perhaps you have some other things that you need to do to get ready for the task; now is the time to start doing those. READY: a task that is ready to be done now

WIP states: (W.I.P. = Work In Progress) things that are being worked on DO: a task that is being done CHECK: checking over/verifying/testing/validating the work that was done. This can be something we are doing, or it could be that we are waiting for someone else to look it over and approve it. FINAL: whatever needs to be done after the task has been checked and passed. For example, deploying software after it has been tested; billing clients after the client has signed off on a completed project; cleaning up a worksite; etc.

CLOSE states: CUT: the task wasn't completed and we aren't thinking about doing it DONE: the task was completed

(about 13 user-visible states+groups of states there, plus 3 tags below = 16 things for the user to understand well)

groupings of states: OPEN/CLOSE: OPEN states are things that we are thinking about doing. CLOSE are the others (CUT and DONE are CLOSE, and everything else is OPEN). TRACK: tasks that we plan to complete (and so they need to be kept track of). TODO or WIP

tags: BOOKED: this can apply to ROADMAP and SOON. It means that there is a schedule or plan to start doing this task at some point, so it is not in need of scheduling. WAIT: this can apply to anything in TRACK. It means that the task is waiting before it can proceed, so there's nothing you can do to push it forward now (except perhaps followup with someone else if the task is waiting for them to do something). Some reasons that a task may be WAIT are that it may: have been placed 'on hold' by you; be waiting-for someone else to do something; be dependent on some other task and waiting-for that task to complete; be waiting for time to pass or for some external event to occur. DELEG: this can apply to anything in TRACK. It means that you have delegated/assigned/hired someone else to do this task, so there's nothing you can do to push it forward now (except perhaps followup with the delegee)

predicates: actionable: Things that you might work on now. (READY or WIP) and !WAIT and !DELEG needsYou: Things that need you to do something (either do the task, or plan for it to be done/schedule it/push forward its planning) . actionable or (TODO and !BOOKED)

some other potential tags: IMP/LOW URG QUICK/LONG FLAG WARN QUESTION MAYBE NEXT LATER RELY microaction tags: dec stew todg followup rely? substates of WAIT? task types/contexts such as call meet errand? next? contexts like HOME, OFFICE? Or just combine these with categories to make intersection categories; "home" is a category which conceptually represents the "life" category with the "home" context. This means you can't quite represent something like "work task: when home, pickup that folder that you accidentally left at home", but that's probably worth the simplification (you would represent this as a "home" task even though it is conceptually a "work" task, not a "life" task). also maybe also add DO substates GREEN YELLOW RED, and add new OPEN states RELY and LATER and/or CLOSE state HOLD want a state like LATER or HOLD b/c sometimes a task in IDEA is being rejected for now but not permanently; want to get it out of IDEA so that it doesn't take up your attention when you go thru IDEA looking for things to move into ROADMAP. Not sure if we should have both an OPEN and CLOSED state of this sort, or if just one, which one. If just one, probably name it HOLD.

yeah, i think we want a CLOSE state HOLD, and an OPEN state RELY. We want a HOLD b/c when you decide you aren't going to do something in the forseeable future, you don't want it cluttering up IDEA. We want HOLD to be CLOSE b/c, like counting the number of open tickets in a foss project, you want the user to be able to minimize the number of OPEN things. We want a RELY b/c it's true that sometimes you delegate something with enough trust that you expect it to be taken care of even if you don't track it, and when this happens, you don't want it cluttering up TRACK.

BOOKED
WAIT
DELEG

actionable := (READY or WIP) and !WAIT and !DELEG needsYou := actionable or (TODO and !BOOKED and !WAIT and !DELEG)

note: the transitions shown here flow in the direction of progress or at least increasing committment, except for transitions to HOLD or CUT. But in actuality, motion in the direction of decreasing committement is possible as well, eg moving something from ROADMAP back to IDEA.

note: in an actual statechart, there would be multiple states inside of WAIT, DELEG, BOOKED, to represent when each of these things are true or false; and maybe more states inside them as well.

and why we left some other things out:

hmm, let's take out BOOKED and SOON too. SOON 'should' be a tag in some sense, and BOOKED is only necessary as a status (rather than a tag) because it needs to apply to both ROADMAP and SOON -- if there were just ROADMAP it would just be a substate of ROADMAP, which can be expressed as just a tag. It means that getting-ready-for things have to depend on a tag (SOON), but that may be less complicated than having two otherwise unnecessary states.

note: the transitions shown here flow in the direction of progress or at least increasing committment, except for transitions to HOLD or CUT. But in actuality, motion in the direction of decreasing committement is possible as well, eg moving something from ROADMAP back to IDEA. Similarly, there is no edge from DELEG to NO_DELEG, but in reality it's possible to take back a task which was delegated.

? SOON*? BOOKED*
? NEXT*
MOTION
? LATER*
DELEGATION
? RELY*
? X: an anonymous orthogonal region containing two states named X and NOT_X; implemented as a tag named X

actionable := (READY or WIP) and !WAIT and !DELEG needsYou := actionable or (TODO and !BOOKED and !WAIT and !DELEG)

orthogonal state tags: WAIT DEP DELEG

WAIT vs LATER vs DEP: DEP means waiting on a dependency. WAIT means waiting for anything else. LATER means waiting for something far off, so don't bother showing this task in some views. These are all implemented as subtags of STOP; note that you could have a WAIT LATER or a DEP LATER.

substate tags (tags that are only valid upon a single state; i feel like these are simpler somehow): SOON BOOKED NEXT LATER RELY

some other potential tags: IMP/LOW URG QUICK/LONG FLAG WARN QUESTION MAYBE

substates of WAIT?

microaction tags: dec stew req followup?

---

    alternately, I could be important, and i could be LOW (UNimportant). r would be ROADMAP, nothing would be BOOKED, and R would be READY; or, r would be IDEA, nothing would be ROADMAP, and R would be BOOKED
      the reason i am even considering the schema where lowercase = -1, blank = 0, uppercase = 1, rather than the more natural blank = -1, lowercase = 0, uppercase = 1, is that with importances, it would be annoying to clutter everything with 'i' for the default (no importance tag; neither IMP nor LOW). However, i think lowercase=-1 is probably too unintuitive, so strike those.

---

  1. # Statuses

Statuses and status-like tags:

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

Predicates:

See also Appendix: etd task status statechart and list of predefined tags.

Status and status-like tag key bindings: NEW(n) IDEA(i) ROADMAP(r) READY(e) DO(d) CHECK(h) FINAL(f)

SOON(s) BOOKED(b) LATER(l) NEXT(x) WAIT(w) DEP(p) SNOOZE(z) SAY(a) REQ(q) DELEG(g) RELY(y) FOLLOWUP(u)
DONE(o)
CUT(c) STOP(t)

consider deleting BOOKED, LATER, SNOOZE, RELY, and replacing with one tag, ASIDE or OK or OKAY or UNTRACK or QUIET or MUTE, which indicates that you don't need to track this too closely (done)

---

old: (D) 2022-01-17 org could represent HOLD as just going back to IDEA. The difference is that HOLD is not in OPEN, IDEA is in OPEN

---

---

---

is what i want one of these 'transient mode's? Isn't that what hydra does? some ppl use transient instead of hydra. Apparently transient came from magit, and is now bundled with emacs 28.1+. https://www.google.com/search?channel=fs&client=ubuntu&q=emacs+hydra+vs+transient https://github.com/practicalli/spacemacs/blob/main/why-spacemacs/transient-state-menus.md https://news.ycombinator.com/item?id=15314571 i guess spacemacs has its own transient state machinery? See spacemacs

https://www.google.com/search?channel=fs&client=ubuntu&q=spacemacs+transient+vs+hydra+vs+magit+transienthttps://www.google.com/search?q=spacemacs+define-transient-state+vs+hydra+vs+magit+transienthttps://www.google.com/search?q=%22spacemacs%22+define-transient-state+vs+%22hydra%22+vs+magit+%22transient%22https://www.google.com/search?q=%22spacemacs%22+%22define-transient-state%22+vs+%22hydra%22
define-transient-state: https://github.com/syl20bnr/spacemacs/search?utf8=%E2%9C%93&q=define-transient-state. spacemacsdefine-transient-state is defined in core-transient-state.el. Oh, actually, that's a wrapper around hydra. I wonder what it adds.

"I think hydra is more suitable for semi-modal interfaces (where the bindings stay active until you exit the hydra). It's possible with transient, too but more complicated. Transient is most useful to invoke command line applications because of it's infix arguments which hydra does not support. If all you need is a simple command dispatcher with a visible menu both will do."

https://magit.vc/manual/transient/Comparison-With-Other-Packages.html#Hydra

i think i'll just use a hydra

---

---

done:

---

---

arst dh neio '

in qwerty:

asdf gh jkl; '

other 'big' keys include SPACEBAR, TAB, ENTER, BACKSPACE.

here's the default orgmode bindings in agenda views:

a: org-agenda-archive-default-with-confirmation r: org-agenda-redo s: org-save-all-org-buffers t: org-agenda-todo

d: org-agenda-day-view h: evil-backward-char

n: evil-search-next e: org-agenda-set-effort i: org-agenda-diary-entry o: delete-other-windows

': self-insert-command

f: org-agenda-later g: (prefix key: d: org-agenda-toggle-time-grid, g: evil-goto-first-line, r: org-agenda-redo) -- did i set this or is this default? i think i set this b/c according to docs, g is usually org-agenda-redo, and also G is usually org-agenda-toggle-time-grid, but now G is evil-goto-line. But i can't find where i set it. Oh.. it's in layers/+emacs/org/packages.el. I don't think i did that, i think it was spacemacs. They also did j and k and RET. See also https://develop.spacemacs.org/layers/+emacs/org/README.html#key-bindings-1 j: org-agenda-next-line (by default this would be org-agenda-goto-date but spacemacs overrode) k: org-agenda-previous-line (by default this would be org-agenda-capture but spacemacs overrode) l: evil-forward-char ;: org-timer-set-timer

RET: org-agenda-switch-to TAB: org-agenda-goto SPACE: org-agenda-show-and-scroll-up BACKSPACE: org-agenda-show-scroll-down

---

BayleShanks RecentChanges Bayle Shanks's website
Comments on notes-organization-old-organizEtdDesignOld1 This page is read-only View other revisions Administration
Last edited 2022-02-12 17:48 UTC by BayleShanks