GenTaskwiki; a tw-specific, project-centric, logic-driven hierarchy

[linuxcaffe]

This great-big feature request seeks to answer the question
"where should I find the wikified version of this task?".

It rests on a number of suppositions

• users of this plugin have a $TASKDATA environment variable, usually ~/.task.
• it is desirable to keep task data together, for ease of use and portability.
• wiki-tasks is different enough from vimwiki, that it should not use ~/vimwiki/ by default.
• a real-world project may need it's own files directory and/or it's own sub-wiki.
• a (sub)project can have it's own folder (../foo/index.wiki) or wiki (../foo.wiki) but not both
• wikified tasks could be in any wiki, and in multiples, no problem, but
• a known or anticipated location for each task within a wiki would be preferable.

So considering all of that, it's still not immediately obvious where a specific task should be found within an automatically-generated wiki hierarchy, but it's possible.

Let me start with the $TASKDATA/index.wiki and $TASKDATA/project/index.wiki and work from there. Like the subject-line says, this is a "project-centric" idea, and presumes a hierarchy that follows a tree of projects and subprojects. A project or sub-project will only get it's own folder or wiki if the user creates it, but if it does exist, we can follow a convention, and work down the tree logically, from the highest branches to the trunk.

As a more complex example, let's locate the proper wiki entry/ file for the following task;

task add proj:tw.web.ui choose initial color scheme

Where should this go?
We'll start from the most granular possibility, and work towards the simplest;
(the first one that exists is the correct place for this task)

• if exists $TASKDATA/project/tw/web/ui/index.wiki

then the ui sub-sub-project has it's own folder

• if exists $TASKDATA/project/tw/web/ui.wiki

then the ui sub-sub-project has it's own wiki

• if exists $TASKDATA/project/tw/web/index.wiki

then the web sub-project has a folder, look under heading == ui ==

• if exists $TASKDATA/project/tw/web.wiki

then the subproject has a wiki, look under heading == ui ==

• if exists $TASKDATA/project/tw/index.wiki

then the project has a folder, look under == web, === ui sub heading

*if exists $TASKDATA/project/tw.wiki

the project has a wiki, look under == web, === ui sub heading

• if exists $TASKDATA/project/index.wiki (and it will exist, or be created)

the project has no folder or wikis, look under == tw, === web, ==== ui heading.

Without any sub-folders or sub-wikis, all tasks with projects will be listed under project-driven headeings and sub-headings in $TASKDATA/project/index.wiki.
Tasks with no project are all listed in $TASKDATA/index.wiki (the root of the taskwiki tree)

This scheme allows for things to start small, and if a project or sub-project needs to add a folder full of related files, or it's own sub-wiki, then related tasks can be automatically moved to the right place, inter-wiki links are automagically (re)generated.

thanks for reading through all of this, I hope at least some of it makes sense :)

[linuxcaffe]

The process to scan the tree, to find the highest appropriate branch, is obviously not something for humans to do, but part of the process of generating the whole taskwiki, and of placing new additions. I see most of the taskwiki structure above to be programatically generated, wikified tasks, project heading structures, and inter-wiki links, but at the same time I DO see a good range of flexibility within those constraints.

With the above described scenario, within the taskwiki tree, tasks are placed under the appropriate = (sub)project = heading, wherever that might be, but there should then be full flexibility to re-arrange tasks under the same heading, change the order or indentation and mix any other text or wiki elements, as long as the task-text_objects and hierarchy remain intact.

Unlike almost every other taskwarrior "front-end", a taskwiki (as described above) would have a fairly rigid structure (project-tree built around your existing sub-folders and sub-wikis under ~.task/) and the sorting of tasks within a sub-heading (let's call that a project-node) will be basically up to the user. The only task sorting options are those that vim offers, not taskwarrior. A new task added should be appended to the bottom of the correct project-node, but after that, a user should be able to move it around that node without breaking functionality. This allows projects to be arranged or described to match the "real world", and to take advantage of the "wikiness" of it all.

And, there's nothing stopping users from inserting another copy of a wikified task in any other.wiki file, anywhere else outside of that tree. Vimwiki-task won't be able to arrange things the same way, but should still be able to push and pull changes to individual tasks, from any wiki file, anywhere on the system.

[linuxcaffe]

I used to think that for those tasks that needed to be in a wiki, that the taskwarrior tag "+wiki" could drive inclusion. Now, on considering a generated taskwiki tree that could contain all tasks, a better idea might be a "+nowiki" tag that cause those tasks to be excluded from the process.

In the same way that tasks within a project-node could be re-arranged at will, the nodes within a subheading would be generated in a default order (desc? id?) but those sub-nodes could be manually re-ordered within that node, as long as it didn't alter the hierarchy.
For it to act as a project-node, each wiki project-heading would have to exactly match the (sub)project name, but these could be mixed with non-project-node headings and any other vimwiki markup.
.
The examples above (within ../project/tw/index.wiki or ../project/tw.wiki) could look like;

= tw = project                  6 pending - from 2011-11-04 to 2014-01-01
a paragraph of wiki-text with any amount of wiki markup
   - [142] taskA desc of a folded task  (2014-01-01) +thistag,thattag [2]
   - [121] taskB desc of another task with lo..(2013-04-22) +othertag [1]
== resources ==
one of several paragraphs
random text and [[random|link]]
== web == project               4 pending - from 2011-11-04 to 2013-11-16
   - [43] taskD folded task with no tag                  (2013-11-16) [3]
   - [[random|link]] and random text
   - [17] taskC a task with no annotation               (2012-11-14) +tag 
=== ui === project              2 pending - from 2011-11-04 to 2013-10-07
   - [220] taskE has no tags or annot but a due date, and a..(2013-10-07)
   - [134] taskF has  a checklist                  (2011-11-04) +atag [4]
        - [ ] thing1 - a TODO, not a task
        - [X] thing2
        - [ ] thing3
another paragraph of wiki-text

The origin-annotation could still be used, and it would override the taskwiki-tree behavior, but it should be the exception, not the rule, and otherwise the proj:name.sub.sub is the key.
(this text mockup now includes examples of #13 and #14)

[linuxcaffe]

A project-node takes the form of a heading, but it is distinct for several reasons, most importantly that it is recognized as such by it's location within the extended, inter-wiki hierarchy and that it has a matching name, Because of this, I think it would be important to indicate this project-node status with syntax highlight and/or displaying "project" after the heading, as illustrated above, and a folded project-node could contain some summary information too, like;

== web == project                4 pending - from 2012-11-14 to 2014-01-01

[linuxcaffe]

some interesting work along these lines (another vim plugin used as an example) written by Abhijit Nadgouda, in https://github.com/vim-scripts/taskmanagementvim. The github is unmaintained and under-documented, but his blog-post here: http://ifacethoughts.net/2008/05/11/task-management-using-vim/ describes the plugin, and his methodology.

To me, the interesting part here is the use of vimgrep across a pre-defined wiki directory, distributing files and aggregating reports. but imagine it vimwiki-tasks style :)

[teranex]

I'm glad you mentioned the 'Task management using Vim' article, as that basically describes how I have been doing task management for the past two years. I think I even read that article when I was setting up my method :)
Here is how I did it:

• I extended the vimwiki syntax so I could add due dates and tags
• I had one vimwiki file with some general tasks
• And for each project I also had a file with tasks (+ notes etc) for that project
• I wrote a Ruby script which would grep through the entire wiki to find all the tasks which were overdue, due today, tomorrow, and in the rest of the week.
• This script would run daily on my Raspberry Pi and send me a daily mail with an overview of the tasks.
• A wrote another Ruby script which would also grep the entire wiki to find all the tasks which where due in the next 10 minutes.
• For each of these tasks (if any) the script would send me a mail /and/ a notification to my Android devices (using PushOver), as a reminder/alarm that I had to do that task.

While I'm still a big fan of keeping all my notes etc together in Vimwiki, since a few months I have the feeling that this system doesn't suit my needs for taskmanagement anymore. Mainly because I didn't have a good overview anymore of which tasks I had to do when and which tasks where still somewhere in a 'queue' waiting to be done someday, because they were scattered around in the vimwiki files, and the only way to find them was to Grep, which takes to much time, is not a nice presentation and does not give any information on which task I should work next.
I also often had a lot of e-mails sitting in my inbox which still needed some action. + Had to check a few different bugtrackers (company, clients, github,..)

Now with taskwarrior, I have everything in one place and can quickly see which tasks I have and which tasks I should be working on. Filtering is also easier than ever and only takes a fraction of a second. For me taskwarrior is now the one central place where all my tasks and todo's come together:

• tasks which I manually
• tasks from vimwiki thanks to vimwiki_tasks
• issues from all the bugtrackers thanks to bugwarrior
• Emails which need a followup (I use tb2taskwarrior which I modified to annotate the task with a link to the mail in thunderbird (using the thunderlink addon), so I can even open the mail directly from taskwarrior using the taskopen script)
• Websites which I still need to take a look at are added through a custom Pentadactyl command (again, with the actual website as an annotation so I can directly open it using taskopen)
• As an added gain I can now also easily create recurring tasks, something for which I used Google Calendar until now

And I modified my daily overview and notification-scripts to simply get the correct tasks for the overview and the notifications directly from task. The notification script now even runs every 5 minutes on my Raspberry Pi as taskwarrior is so fast :).

In fact after using taskwarrior for 2 or 3 weeks now I see that I add most of my tasks directly using the CLI interface, rather than using vimwiki_tasks. I still like how vimwiki_tasks works however, as I can easily insert an overview of tasks of a project inside the vimwiki file (:InsertTasks proj:foobar, I committed this yesterday). Also, while taking notes during a meeting I can quickly add one or more tasks without having to switch apps. But for me, Taskwarrior will always be my 'one through source of tasks' and detailed info.

So to summarize, I don't really see the practical use to generate a complete wiki with all the tasks with complete info, while there already is a completely practical, fast and nice interface? When you want all the tasks with all the available info completely in Vimwiki, then why use taskwarrior at al?

[linuxcaffe]

Yes, taskwarrior itself is awesome and hard to beat, but where it falls short is in detailed and freeform description of project details and related assets. A vimwiki view of a project should show all related tasks, as well as any other related text and markup. Because there's no harm in having tasks in both tw and vimwiki-tasks, and because creating those task-links one-by-one would be laborious and error-prone, a function to populate a project would be preferable. The idea that you could go from a grid-view to an outlined wiki-view for each project offers the best of both worlds, and having that project in a predictable, expandable hierarchy would be better still.

That said, if you're re-discovering tw, and moving away from wiki-based tasks, doesn't that sort of negate the need for vimwiki-tasks altogether?

Don't get me wrong, having embedable tw tasks in vimwiki might be handy, but it it's usefulness diminishes when only the subset you manually entered is present.

says me :-)