-
Notifications
You must be signed in to change notification settings - Fork 32
Envisioned use cases
Most of the times, I use taskopen/taskwarrior to group documents and make them easily accessible. A task could be a long-term pet project, a reading list, or a repetitive chore (e.g. backup checklist). In all these cases, a taskwarrior task stores meta information and state for a collection of documents/links/etc. Taskopen could be used to achieve a better organisation of documents by adding a meta data layer that allows filtering by contexts and other taskwarrior concepts. This use case would benefit from the following features:
- find task for a given file
- archive documents (must respect other references to the same document)
- moving/copying annotations to another task
A task referencing a given file can be found by using taskwarrior's filter functionality to search in annotations, e.g.:
task /path.to.file.ext/
Note, that using . instead of / resolves the problem of escaping the latter.
Instead, the search term is interpreted as a regular expression.
Yet, there is a little bit of ambiguity left.
This might be solved by a new parser implementation in taskwarrior, though.
Archiving is achievable by an external script that checks whether the file is referenced by any other active task, moves the file and modifies the annotation correspondingly.
Moving/copying annotations is also achieved by an external script.
The only challenge with this is how the ID of the target task is passed to the script.
A viable and simple option is the addition of a --args option in order to fill an environment variable that can be referenced in the command.
Recently, I have been experimenting with applying a kanban scheme to taskwarrior. My observation is that the kanban methodology helps with structuring and 'prioritising' tasks without imposing much management overhead. Although taskwarrior does not provide a nice board-like visualisation on the command line, it still comes with some features that I miss in other tools. Most notably, kanban tools tend to use a strict separation of boards. A board is often associated to a particular project such that tasks cannot be shared between multiple boards. In taskwarrior, I can define arbitrary contexts based on task attributes to refine what tasks shall be shown in my 'board'. Think of it as context-defined boards rather than project-defined boards.
As a first step, I specified a UDA in taskwarrior to define the columns of my board. I like having a backlog, ready, work-in-progress and a done column. The done column may not be essential for everyone, but I like to use it as a review stage. I also added a new board report to my taskwarrior config. The board report shows all tasks with a column assigned, sorted first by column and secondly by urgency. Aliases blg, rdy, wip, and done refine the board report by filtering individual columns.
In addition to the notion of a board, I made a habit scheduling tasks to a certain day in the current or next week.
I use taskwarrior's schedule attribute for this and defined a couple of additional reports.
The week report shows all tasks that are scheduled before the end of the week.
Note, the dateformat a(V) helps with identifying the weekday and week when I want to focus on the task.
The w2 report does the same for tasks that are scheduled after end of the week but before end of next week.
Furthermore, I use the next report to only show actionable tasks (pending, not blocked, and not scheduled or scheduled before now) of the ready and work-in-progress column.
Taskopen augments this scheme by allowing me to add textual notes to the tasks in which I document progress. It also helps with storing related state such as web pages so that I can close the corresponding browser tabs when I'm not working on the task. Attaching files such as data sheets to tasks also helps with making all necessary information available at one place (i.e. the task).
With the rewrite of taskopen, I would like to refine this scheme.
An additional taskban wrapper script may help with providing a clean and uniform interface to taskwarrior and taskopen for this use case.
Yet, taskwarrior's alias mechanism might also be leveraged for this.
The following sections sketch further ideas and observations in this use.
For me, a project often starts with a single task and an attached notes file that I use as a scratchpad to develop and document ideas. When the ideas mature, a single task usually becomes too coarse grained to structure the work. Thus, the initial task must be divided into multiple tasks that I can focus on separately. At this point, it becomes a milestone task that I tend to keep alive as a) it references the initial notes/thoughts and b) can eventually be reused for documentation of the project. The (sub)tasks flow through the swimlane and will eventually leave the scope of the board. Tasks that have been completed but may need to be revisited are kept in the done column to keep them accessible. It is only safe to mark a task as done and thereby remove it from the board, when a task is truly finished, and when every piece of information attached to it (e.g. notes, files) have been transferred to the milestone task. It is a good habit to delete obsolete files and archive others so that a clear structure remains in the file system even without having the taskwarrior data readily accessible. Furthermore, archived data should reference the UUID of the milestone task so that the information can be queried from taskwarrior even for completed task. The milestone task thereby defines the life cycle of the project, i.e. it is the first task to be started and the last task to be completed.
Typical operations for which a taskban wrapper helps are:
- splitting of tasks
- moving tasks between columns
- copying/moving annotations
- deleting attached notes/files when a task is deleted
- only if the notes/files are not referenced by another task
- archiving (or deleting) attached notes/files when a task is done
- ask user whether information is still relevant
- only archive/delete if notes/files are not reference by another task
- opening attachments of completed tasks
The key idea behind this has already been described above: tasks are scheduled to weekdays. The week and w2 reports show the tasks scheduled for this or the next week respectively. In other words, the kanban columns are the first level of structuring the task set whereas the scheduling acts as the second level.
Taskopen can help with restoring the context (e.g. browser tabs, opened documents) of the +READY work-in-progress tasks.
A taskban wrapper could help with scheduling and rescheduling of tasks.
- Do not mark tasks as done if they might be revisited or their annotations need to be kept accessible.
- If a task is done or deleted, attached notes/files should be cleaned-up, i.e. copied to another task, archived or deleted.
- Rarely use due dates (e.g. on milestone tasks or if dates are truly fixed appointments, expiration dates). Instead, consider wait dates to hide tasks that cannot be reasonably worked on until a certain data. Together with recurrence, this is a good way to define chore tasks for backups, certificate renewal, etc.
- Do not use priorities for ordering tasks as they tend to change and increase maintenance overhead. Yet, if used in the sense of general importance they can help to identify droppable workload.
This is achieved by an external script aliased within taskopen.
The only challenge with this is how the ID of the target task is passed to the script.
A viable and simple option is the addition of a --args option in order to fill an environment variable that can be referenced in the command.
This can be implemented by an external script, grouped and aliased within taskopen. In any mode taskopen will show alternate actions on all matching annotations so that the user can select whether to archive or delete an annotation. Furthermore, the filter command allows restricting this to files that are not referenced by other tasks.
Additionally/alternatively, a hook or alias can be used in taskwarrior to check on deleting/completing of a task whether any files need to be archived or deleted.
This is textbook example for taskopen's batch mode. Yet, it should be ensured that the actions' commands fork into background.
This is best done in a wrapper script.
This is best done in a wrapper script, which may call taskopen to copy annotations.
These can be actions in taskopen or implemented by a wrapper script.
This is already available taskopen via the -A switch.