search

teranex / vimwiki-tasks

A Vim plugin to integrate Vimwiki tasks with taskwarrior. Sync tasks between vimwiki and taskwarrior in both directions
MIT License
32 stars 6 forks source link

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

Open linuxcaffe opened 11 years ago

linuxcaffe commented 11 years ago

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

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)

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

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

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

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

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

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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:

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:

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 commented 11 years ago

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 :-)