Are "contexts" extraneous?

[savchenko]

Inspired by https://github.com/djmitche/taskchampion/issues/122. How crucial is this functionality given the existence of "project", "priority", task tag, name and description?

[djmitche]

https://taskwarrior.org/docs/context.html is the inspiration for this, as @srfraser linked in #122.

The GTD model involves limiting focus to only the tasks that are relevant right now, and I can see how contexts might be useful to accomplish that.

I don't personally use contexts, but I have different reports customized to particular uses, which has a similar effect.

So I guess the question is, what is the incremental advantage of explicit context support (a mapping of context -> filter expression, and a configuration for the "current" context) over the functionality already provided by named reports?

[savchenko]

the context would be based on the current working directory

Relying on $PWD might be a little dangerous:

$ cd $HOME; echo $PWD
/home/user
$ unset PWD; echo $PWD

And on a higher level, if we picture task management that is not necessarily computer-centric, how current directory is relevant to the context? As far as I remember, in GTD "context" relates to the location within something. E.g. "home, work, cafe, fresh_morning_mind, good_mood" are all contexts.

Therefore, task with the context of "good_mood" implies "do this when you are in a good mood" and one with the context "home", "do it at home".

[savchenko]

My initial thoughts were that you could configure external commands to run, so that, for example, if basename $(git rev-parse --show-toplevel) returned a string it would be added as a tag or possible to use it in other ways.

It is cool, but wouldn't it be too complicated for majority of the users? I am thinking that TC could certainly have framework-y features like that, but I am a little sceptical if having elaborate workflows by default will do any good to an adoption.

Let's start simple.

[dbr]

I would imagine that by default, TC doesn't have any direct way of inferring context - e.g it would not query or rely on $PWD or current wifi network or anything like that.

If we provide an config option like

get-default-filter-callback = "~/bin/tc-current-context

then technical user could write a script which does things like:

• Filter for issues tagged with the folder name of the current git repo
• Get parent .git folder, if it matches taskchampion-* then filter to only tasks with tc tag (e.g same but more complex mapping of paths->tags)
• Query current network, if it matches suchandsuch then only show tasks with the work tag
• Look at current time, if it's after midday, only show tasks scheduled for today or with a high-priority

One thing with this idea is it would be good if tasks created by default go into the current context - so you could do something like:

$ cd ~/code/myproj
$ ta add Fix thing in my project
$ cd $HOME
$ ta add General thing
ta set-current-context tag:work
ta add Work thing
ta add Another work thing

(however if the output of the callback script is an arbitrary filter string, how to do that is unclear to me)

[savchenko]

then technical user could write a script

This is my favourite part. @djmitche , would you be open to exposing callbacks to end-users? We can add a warm message reminding about an importance of contributing back and host the most interesting solutions within the TaskChampion org.

[djmitche]

Yeah, I think so. TW has "hooks" which I don't think we want to duplicate, but would be a good model to look at before defining our own implementation.