gtg-user team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Sat, May 22, 2010 at 03:47:44PM +0200, Elias Jarlebring wrote:
> * Contexts
> 
> "Context" in GTD is a way to classify a project or action such that
> you are only confronted with those projects and actions which you
> can actually do in the current location or situation. My first
> obstacle in using GTG was the implementation of context. Although
> there is no "context" concept in GTG, the functionality can be
> achieved with the concept of tags. For instance, the tags
> corresponding to context are in my case @office, @internet, @home,
> @city, @anywhere. Note that  if you right click on a tag in the tag
> list you can toggle "Visible in workview" such that you can untoggle
> the contexts which are not active at the moment.

At the Ubuntu Developer Summit gtg session, RAOF and I had a brief aside
about context switching and gtg, but thought that it fit more at the
desktop level than just gtg.  The idea being that your computer desktop
would track your "Context" and then applications could adjust themselves
when you change contexts.  So for instance, in gtg you might select the
task you're working on, and this could cause certain documents to load
up in web browser tabs, then when you move to a different task with a
new context, those tabs are hidden.

Anyway, we all agreed it was pretty blue sky, but maybe someday.

> * The inbox
> 
> The "inbox" is an important concept in GTD. That's where you throw
> things which you don't want to forget but also do not want to
> "process" at this moment. In GTG, my inbox are those tasks without
> any tags. In this way I can quickly add stuff to the inbox with the
> quick-add text field, and I can see the inbox by selecting "Tasks
> with no tag" in the tags sidebar. (More on quickly adding to stuff
> to inbox below.)

I've started using this approach as well.  I like to track the count of
number of work tasks each day, so I can control the quantity of work I
commit to.  So I have a @Work parent task for all projects related to my
job, and I can use the count next to that tag in the tags pane to
measure my status and my rate of task closing.

However, often I find I have a lot of tasks which are tagged that I
might like to work on today but that aren't high priorities.

A thought I've had for this is to better distinguish between tasks with
due dates and those without.  So each day I want to work on the ones
with a due date first, then if time permits after I'll look at ones with
no due date assigned.

Another similar thought would use start dates.  Currently the WorkView
shows only tasks that start today (or earlier) or that have no start
date specified.  For my workflow I apply start dates to all my tasks (so
I can put ones in the future that I don't think I'll get to today).  It
might be nice to instead have an ability for WorkView to exclude bugs
without start dates specified.  This approach would give a way to track
those 'someday-maybe' tasks - you would tag them but just leave the
start date omitted.

> * Seamless access to todo-lists
> 
> David Allen stresses the importance of having an effortless system.
> If it takes me effort to access a todo-list, i.e., GTG in this case,
> I often find myself resisting using it.

I agree with this, and at least for my workflow (and my several hundred
tasks), it's not quite there.  I find I often need to put quite a bit of
time each day into sorting, filtering, and prioritizing my tasks, which
I wish gtg could help me with.

But gtg is still early in its development (only to version 0.2!) so the
fact that it's already helping me be better organized (even my boss has
noticed!) makes it worth the trouble.  And has gotten me turned into a
gtg developer now!

> I want to be to able to
> access GTG quickly and quickly jump back and forth between a screen
> with GTG and a screen where I am currently working. This can be
> achieved with virtual desktops and global keyboard shortcuts. I set
> it up in KDE as follows.
>  1) Make sure you have the "pager" widget on your panel.
>  2) Right click on the pager, select "Configure desktops.." and set
> "Number of desktops" equal to two
>  3) Start System settings -> Keyboard and Mouse -> Global keyboard
> shortcuts
>  4) Select KDE component "Kwin".
>  5) Scroll down and click "Switch to desktop 1". Click on "None" and
> press "F11" on your keyboard
>  6) Repeat step 5 with "Switch to desktop 2" and "F12" and apply the
> settings.
> 
> In this way you can switch between desktop 1 and 2 using the keys
> F11 and F12. I start GTG in desktop 2 and do work on desktop 1.

I am lazy and just use multiple monitors.  ;-)  But this sounds cool.
There's also an indicator thingee for displaying your current tasks, but
I don't know if it works on KDE, and it's read-only afaik.

> * Effortless adding to inbox
> 
> In order to really use the inbox without thinking about it, I
> personally have to able to add stuff to it with just one keyboard
> combination.

Note there is now also a command line tool 'gtcli' (I'm open to a better
name!) which permits listing, closing, etc. tasks.  You might find it
handy for further integration with KDE.  It is included in the 0.3
tree, and also I have a branch with it for 0.2.

>   Since I also want the new task window to be centered (and in
> focus) I also configure special window behavior:
>     * Make sure you have a gtg new task window open
>     * Go to "Configure window behavior -> Window-specific"
>     * Click New -> Detect window properties and click on the new
> task window
>     * In the Geometry tab: set Placement -> Force -> centered
>     * In the preference tab: set Keep above -> Force -> Check
>     * In the preference tab: set Accept focus -> Force -> Check
>     * In the Workarounds tab: set Focus stealing prevention -> Force
> -> None (!)

This sounds useful in general, you ought to think about proposing a
patch that adds these abilities to gtg_new_task.  :-)

> * Weekly review adding script:
> 
> As a part of my weekly review I have a number of actions (subtasks)
> and a project (task) which are things I want add, e.g., "Do sports
> 1", "Do sports 2", "Water plants (wednesday)",  "Do stretching
> exercise 1", "Do stretching exercise 2", etc. This is quite long
> list in my case.

Yeah, this sounds like the 'recurring tasks' feature which a lot of us
hope to see in gtg.

Your workaround seems sane, although I use a different approach to
workaround it.  For each task that is going to recur, I write it
like this:

 "Water plants; then replan for next Wed"
 "Clear inbox by 50%; then replan for tomorrow"
 "Do filing 2 hrs; then replan for next month"

This then reminds me when I do these tasks to instead of marking them
Done, to instead change the start date to the next date occurrence.

Anyway, it's in the plans to make gtg able to handle recurring tasks
itself, just I think no one has sat down and done the coding.  See the
bug report for details on how we think it should be implemented if
you're at all interested in coding it.

> * Some unresolved issues and inconveniences:
> 
> Processing the inbox requires that I "move" tasks which do not have
> tag to become a subtask of another task (in GTD terminology a
> "project"). The only way I know how to this is in GTG is with drag
> and drop. This requires me to switch to "All tasks", find the
> unprocessed inbox entry and drag it to the correct task. It would be
> nice if there would be a way to easier do that.

In gtcli the routine to add a new task is:

def new_task(title, body):
    """ Retrieve task via dbus """
    timi = connect_to_gtg()
    timi.new_task("Active", title, '', '', '', [], body, [])

Those parameters correspond to status, title, duedate, startdate,
donedate, tags, text, and subtasks.  So you could try modifying this
routine in gtcli to accept arguments for specifying the tags directly.
Maybe also to set start dates if you want to run the script on Sunday
to have it set up your recurring tasks for each day the coming week.

My gtcli for 0.2 branch is here:
  http://bazaar.launchpad.net/~bryceharrington/gtg/command-line/files

You can download just the gtcli file from there and use it against your
stock 0.2.x gtg from Kubuntu Lucid if you don't want to be running gtg
from bzr.


There is not a mechanism in gtcli to add a task as a subtask of another,
but I think that should be possible to add.  If you'd like to try it,
have a go and feel free to shoot me patches and I'll help you get it
working and incorporated.

> I have also not found a way to implement a "Someday maybe list".
> Currently, I have a tag and a task called "someday maybe" where I
> put those entries. In this implementation, the distinction between a
> "someday maybe entry" and an "action" (or project) is not quite
> sufficient for my workflow. Someday maybe entries are things which I
> don't want see except during the weekly review. With the current
> implementation, they pop up once in a while when I'm just editing my
> lists, stealing a bit of my attention. This is more serious than it
> sounds since my someday maybe list consists of many "heavy" entries.
> 
> The same holds for a "reference list".
> 
> Does anyone have a better "someday maybe" or "reference" solution?

Yeah, a couple thoughts.

First is like I said before, it'd be nice to have gtg be able to
distinguish tagged tasks with no start date specified separately, so
that would work as a "someday maybe" list.  So like a modified version
of the WorkView.

Second, like I mentioned, with my workflow I rather aggressively
reschedule tasks forward weeks or months as my solution to 'someday
maybe' (I've got a pimped out 'Set start date...' context menu to do
this.)  That allows them to be categorized into my tag tree, but I don't
need to think of them for a while.  And I can be sure they'll bubble up
some day so every so many days I have to give them some consideration.
Sort of like the 'tickle folder' in GTD, but better.  However, the
downside is I spend a lot more time "considering" these tasks than I'd
like, so I am definitely looking for better solutions.

A third idea would be to add a 'someday' option to the startdate field.
We already have a 'someday' option for duedate, so conceptually it seems
clean.  Then you just set the start date of all your "someday maybe"
tasks to that, and we would configure WorkView to exclude them, and
maybe add a 'Tasks for someday' filter under 'Tasks with no tags' so you
can easily get to them as needed.

Anyway, sorry this turned into a gargantuan email reply, but if you read
this far, let me know what you think of all these ideas.  If you're
interested in hacking on implementing any of them in gtg, we could
discuss further with Bertrand and others to make sure there is agreement
with the design.

Bryce