[Kolab-devel] Tasks, GTD and Kolab

[Christian Mollekopf]

On Monday 24 September 2012 18.43:08 Thomas Brüderli wrote:
> Hello Kolab devs
> 
> During my vacation I read throgh David Allen's Getting Things Done® and I'm
> now in the process of setting up the newly developped tasks module from the
> Kolab 3.0 web client as my primary tool to manage things.
> 
> While real support for projects and contexts is still missing in Tasks, I'm
> able to circumvent that lack with tags. I just defined my contexts as tags
> and the client allows me to filter the tasks list by these. The same goes
> for projects, they can be modeled as tags or with separate lists.
> 
> And here some basic questions raised in my head concerning the storage of
> tasks in Kolab 3 and the further implementation of the tasks module:
> 
> * The straight-forward attempt to manage tasks in different lists is to
> create IMAP folders representing those lists. With the recent commits in
> git, the web client even allows me to drag & drop tasks to any list/folder
> I have write access to. But what about the Inbox? GTD suggests to have a
> list named "Inbox" to collect tasks in order to process them later on.
> Naturally I want to create a list (i.e. imap folder) named Inbox. But my
> IMAP account already has a folder named INBOX for obvious reasons. Of
> course I can name it differently or create it as a subfolder of Tasks or
> whatnot but I assume lots of future users running into the same issue.
> Another possibility would be to give it an arbitrary name and to add an
> option to the client which allows one to claim a certain folder to be the
> inbox for tasks. And how to store this information? a) use the
> "tasks.default" IMAP annotation for that or b) define a new special type
> annotation like "tasks.inbox" or c) store it individually on each client.
> I'd vote for a) or b) here.
> 

I think we should be using just tasks.default.
The inbox should probably just be a virtual folder for the views where you 
display "Projects" and "Contexts", so every item which doesn't belong to any 
Project or Context (depending on the view), shows up in the inbox. So I don't 
think you need an IMAP folder called "inbox" for that purpose.

> * A common use-case is to create a task from an incoming mail. The web
> client therefore has the option "create task" in the mail view. This will
> then copy the mail body and all attachments to the new task item. But in
> order to keep the full reference (maybe a complete mail thread) and to
> avoid duplicated attachments it'd be nice to simply "link" the original
> mail message with the task record. The message ID could serve as a unique
> identifier but I'm wondering how to store that reference in the Kolab task
> object. The Kolab XML Format 3.0 doesn't specify a dedicated attribute for
> that. It could, however, go into a custom property. Any suggestions?
> 

An attachment containing an uri seems like a clean way for this. Not sure what 
kind of uri would be suitable though.

> * Similar question about "flagged" tasks. Nowadays, most task management
> tools out there, provide a way to flag/mark/star a task as important and
> to filter the list by such flagged items. Here again the Kolab format
> doesn't specify an attribute for such a mark. The current implementation of
> the web client uses IMAP flags to store this information but that's
> probably not the perfect way to do so. I'm all ears for a better solution.
> 

There's not really such a concept available in ical, beyond the priority.
So IMO the IMAP flags are fine for this metadata until we decide we do need an 
extra property for this (I don't think it would be a huge problem that this 
data is lost when the tasks are moved i.e. to an ical file). Kmail also uses 
the \FLAGGED flag as the "Important" mark.

Theres of course always the option to just use the priority for something like 
that.

Cheers,
Christian

> Having these few questions answered will hopefully lead us to a basic but
> still powerful tasks management tool ready to be deployed with the Kolab 3
> groupware suite.
> 
> Best regards,
> Thomas
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120926/e5a04ca2/attachment.sig>