Re: Tasks, GTD and Kolab

Christian Mollekopf wrote:
> On Monday 24 September 2012 18.43:08 Thomas Brüderli wrote:
>> [...]
>>
>> * 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.

Sure, that's the long-term goal but as long as we don't have a clear spec
how to store contexts and other pim relations in the Kolab format, I guess
we'll use a physical folder for inbox. But I'm fine with using the .default
suffix just to avoid adding some new specification which we'll drop again
later on.
> 
>> * 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.

OK, I'll try to model such a relation around the attachment feature.
> 
>> * 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.

I'm sorry, I didn't remember my own code correctly (sigh!). The web client
actually uses the priority attribute to mark a task as flagged. Priority 1
equals flagged, anything else is unflagged.

So I guess that wasn't a bad decision then...

Thanks for the reply!

Thomas