Update plans & readme
This commit is contained in:
parent
47f7e9b26e
commit
988f9f9b6e
3 changed files with 106 additions and 57 deletions
69
README.md
69
README.md
|
@ -18,7 +18,7 @@ For that, a task management system needs to enable these three actions:
|
|||
|
||||
# Design
|
||||
|
||||
The most important rule: Everything is a task. There is nothing else.
|
||||
The most important rule: Everything is a task. There is nothing else.
|
||||
|
||||
Projects, Areas, Epics - they can all be mapped onto tasks, and doing so will allow you to leverage the same toolset on everything.
|
||||
A project or epic is a completable task with subtasks - it can itself be a subtask.
|
||||
|
@ -30,68 +30,34 @@ More fundamentals:
|
|||
- UNIX philosophy: use plain text is possible, separate into independent modules
|
||||
- Complete control: Inbuilt reports and attributes should use available configuration, so that the user can change fundamental parts of the system
|
||||
|
||||
## Task attributes
|
||||
## Task types
|
||||
There are essentially 4 types of things we do:
|
||||
- tasks: things to be done once e.g. hand in an assignment, fix a bug
|
||||
- activities: can't be completed e.g. browse the internet, gaming, spend time with family
|
||||
- habits: repeat in a set interval, e.g. go for a run daily, pay rent - sometimes skippable
|
||||
- chores: recur in regular intervals without a strict due date, e.g. do laundry, cut nails - can be postponed but not skipped
|
||||
|
||||
A task has attributes, and each attribute is of one of the following types:
|
||||
- string, timestamp, number, date
|
||||
- a list of each of these(or only string?) is possible as well
|
||||
- it should be possible to restrict a property to a set of values (enum)
|
||||
Even though they won't be clearly distinguished by a single property, they will be mapped through some default properties:
|
||||
- Inspired by [tasklite](https://tasklite.org/concepts.html), habits have a `repeat` property while chores have a `recur` property - both can be frozen.
|
||||
- Tasks and activities may be distinguished by a `size` property, where activities have a special size value of `-`, marking them incompletable. Alternatively, activities may be prefixed with a star as it is done in Todoist
|
||||
|
||||
Special attributes:
|
||||
- id: string
|
||||
- parent: string
|
||||
- entered, modified: timestamp
|
||||
- urgency: number-computed
|
||||
- status: enum-string-computed
|
||||
- virtual tags?
|
||||
- completable: boolean
|
||||
These basic types also incorporate other types:
|
||||
- an area is simply an activity with subtasks
|
||||
- a project is a task with subtasks
|
||||
|
||||
Standard attributes:
|
||||
- tags: list-string
|
||||
- annotations: list-string
|
||||
- wait,scheduled,due,until,recur: timestamp
|
||||
- relativeRecur: boolean
|
||||
- start,stop: timestamp
|
||||
|
||||
Custom attributes
|
||||
- priority, size: enum-string
|
||||
- url: string
|
||||
Since "task" is one of these types, entities of any of these types can be called "items" within the implementation to avoid confusion.
|
||||
|
||||
## User Stories
|
||||
|
||||
- areas
|
||||
- housework projects
|
||||
- GTD
|
||||
- Agile
|
||||
|
||||
## Reports I need
|
||||
|
||||
### Reports I need
|
||||
- Review active projects
|
||||
- Find out tasks to batch when going out
|
||||
- Find things I can do when I am (outside watching the babies e.g. cut nails | focused, wanting to do some (writing|programming) in the morning | unfocused in the afternoon e.g. check mails | taking a break from work on the computer e.g. do laundry | eating/snacking something e.g. watch a video/read a paper | listening to an audiobook e.g. digging, hang out the laundry)
|
||||
|
||||
# Commands
|
||||
|
||||
`add <mods>` - add a new task under the currently selected one
|
||||
|
||||
`<id> add <mods>` - add a new task with <id> as parent
|
||||
|
||||
## Selected Task
|
||||
|
||||
If there is no selected task, the selected task is assumed to be an empty invisible root task
|
||||
|
||||
`cd <id>` - select the given task (alternative names: open,select,ct("change task"))
|
||||
|
||||
`show` - show details for the currently selected task (maybe also subtasks)
|
||||
|
||||
`list` - list all direct subtasks
|
||||
|
||||
`tree` - recursively list subtasks
|
||||
|
||||
## More commands
|
||||
|
||||
For more, see [taskwarrior] for now...
|
||||
|
||||
# Inspirations
|
||||
|
||||
## Taskwarrior
|
||||
|
@ -100,12 +66,12 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
|
|||
|
||||
### Issues
|
||||
|
||||
- A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook.
|
||||
- A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook. This also makes entering tasks more verbose as I have to specify multiple tags repeatedly which could otherwise simply be inherited.
|
||||
- Recurrence is a longstanding issue, but can somewhat be solved by plugins: https://github.com/tbabej/task.shift-recurrence and https://github.com/JensErat/task-relative-recur
|
||||
- UDAs have a lot less options than inbuilt properties
|
||||
- CLI can be too verbose: I am missing some way to set shorthands for attributes, e.g. "p" for project, dates are rather inflexible
|
||||
- Keeping all reports aligned with custom attributes is a hassle, since you can't base reports off each other
|
||||
- ids shift around annoyingly, so you constantly have to look them up
|
||||
- ids change whenever a task is completed, so you constantly have double-check or might complete a wrong task
|
||||
|
||||
### What it does well
|
||||
|
||||
|
@ -118,4 +84,3 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
|
|||
[taskwarrior]: https://taskwarrior.org/
|
||||
https://tasklite.org/related.html
|
||||
https://www.wired.com/2016/03/best-to-do-list-app/
|
||||
|
||||
|
|
18
dom
Normal file
18
dom
Normal file
|
@ -0,0 +1,18 @@
|
|||
# This is a documentation by example of the DOM of Tofo
|
||||
|
||||
attribute.all.type=string
|
||||
attribute.all.order=desc
|
||||
attribute.all.string.order=asc
|
||||
attribute.all.date.order=asc
|
||||
|
||||
attribute.sched.type=date
|
||||
|
||||
context.default=
|
||||
context.work=+work +pc
|
||||
context.config=+config +pc
|
||||
|
||||
report.default=.next
|
||||
report.next=type:task
|
||||
|
||||
item.all.target=.sched || .due
|
||||
|
76
plans.md
76
plans.md
|
@ -2,21 +2,29 @@
|
|||
|
||||
The implementation is split into two parts:
|
||||
|
||||
The [plumber][plumbing], wrapping low-level storage/database access to the database and providing commands such as:
|
||||
The [plumber][plumbing], wrapping low-level storage/database access to the database in verbose commands, and the porcelain, providing a pretty interface to it.
|
||||
|
||||
## Underlying implementation - [plumbing]
|
||||
|
||||
Provides commands such as:
|
||||
- add <mods> -> add a new task
|
||||
- <filter> modify <mods> -> modify task metadata
|
||||
- prune -> delete tasks with status:deleted permanently
|
||||
- <filter> get <prop> -> gets a property of the first task matching the filter
|
||||
|
||||
## Underlying implementation - [plumbing]
|
||||
|
||||
### Tasklite
|
||||
|
||||
To speed up development, I am planning to use [tasklite] under the hood for now rather than developing my own plumbing tool.
|
||||
To speed up development, I am considering [tasklite] under the hood for now rather than developing my own plumbing tool.
|
||||
|
||||
Additional relevant commands:
|
||||
- runsql -> providing low-level access
|
||||
|
||||
### Taskwarrior
|
||||
|
||||
Since I am currently running [taskwarrior], this might also be a good foundation. It is also more tolerant about custom properties than Tasklite.
|
||||
|
||||
It has worse performance and some shortcomings, but these can mostly be addressed by the porcelain layer. A weak point however is that access isn't as powerful as with SQL, e.g. listing all subtasks of a parent can't be done as easily.
|
||||
|
||||
## Taskporc/Tofu
|
||||
|
||||
My own idea for a plumber, conceptually minimal without any convenient shortcuts or configuration - just basic commands to modify and read the database.
|
||||
|
@ -79,8 +87,66 @@ size.shorthand=s
|
|||
|
||||
Adds support for reports, which can also be configured in a separate config file. They can specify queries, limits, sorting and which properties to display.
|
||||
|
||||
Especially important is the support for tree displaying -> using the parent relation, as well as the
|
||||
Especially important is the support for tree displaying -> using the parent relation, as well as incorporating datestamps of parents.
|
||||
|
||||
### Configuration
|
||||
HOME=$XDG_CONFIG_HOME/tofo
|
||||
|
||||
$HOME/\*rc for general configuration - multiple files allow cleaner config
|
||||
-> alternative: directory structure mimicking DOM for UNIX-style, but worse performance
|
||||
|
||||
$HOME/hooks contains hooks:
|
||||
- on-start/on-exit
|
||||
- on-change (any task change, add or mod)
|
||||
- on-add (new task)
|
||||
- on-mod (existing task changed)
|
||||
|
||||
$XDG_CACHE_HOME may contain the current state (context/entered task), since resetting that does no harm. Depending on the implementation, it could also hold a cache of the compiled rc.
|
||||
|
||||
# General plans
|
||||
|
||||
## Task attributes
|
||||
|
||||
A task has attributes, and each attribute is of one of the following types:
|
||||
- string, timestamp, number, date, list (of strings)
|
||||
- it should be possible to restrict a property to a set of values (enum)
|
||||
|
||||
### Special attributes
|
||||
- uid: string-computed (ulid/uuid)
|
||||
- id: string (generated automatically, user-friendly but can be changed)
|
||||
- parent: string
|
||||
- entered, modified: timestamp
|
||||
- urgency: number-computed
|
||||
- status: enum-string-computed
|
||||
- virtual tags?
|
||||
- completable: boolean
|
||||
|
||||
### Standard attributes
|
||||
- tags: list
|
||||
- annotations: list
|
||||
- wait,scheduled,due,until,recur: timestamp
|
||||
- relativeRecur: boolean
|
||||
- start,stop: timestamp
|
||||
|
||||
### Custom attributes
|
||||
- priority, size: enum-string
|
||||
- url: string
|
||||
|
||||
## Command ideas
|
||||
- `add <mods>`: add a new task under the currently selected one
|
||||
- `<id> add <mods>`: add a new task with <id> as parent
|
||||
|
||||
### Selected Task
|
||||
If there is no selected task, the selected task is assumed to be an empty invisible root task
|
||||
- `cd <id>`: select the given task (alternative names: open,select,ct("change task"))
|
||||
- `show`: show details for the currently selected task (maybe also subtasks)
|
||||
- `list`: list all direct subtasks
|
||||
- `tree`: recursively list subtasks
|
||||
|
||||
### More commands
|
||||
|
||||
For more, see [taskwarrior] for now...
|
||||
|
||||
[tasklite]: https://tasklite.org
|
||||
[plumbing]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
|
||||
[taskwarrior]: https://taskwarrior.org/
|
||||
|
|
Loading…
Add table
Reference in a new issue