A few thoughts ... (1) Having a WBS (work breakdown structure) coding may provide sufficient dependencies between the tasks. Child task depends on parents.Message 1 of 9 , Apr 10, 2012View Source
A few thoughts ...
(1) Having a WBS (work breakdown structure) coding may provide sufficient dependencies between the tasks. Child task depends on parents. Sibling task depends on earlier tasks.
(2) WBS coding could be simple one word dotted numbers ...
(3) The todo.txt clients can display the task properly sorted and indented. And possibly make the sort permanent in the todo.txt file.
Make sense?On Apr 11, 2012 6:31 AM, "Paul Beckingham" <paul@...> wrote:On Apr 10, 2012, at 5:23 PM, Ed Blackman wrote:
… Here are my design thoughts. …Speaking from the position of having implemented this elsewhere, I'd like to point out that there are some tricky aspects to this, which warrant careful planning. This is a can of worms.The dependencies themselves are not a problem, but what lies next can be challenging. For example, you might want to think about:- Can one task depend on multiple other tasks?- Is dependency circularity allowed? Probably not.- Can you easily determine whether a task is blocked? Probably not, because it will involve walking a chain of dependent tasks to the end.- Can you easily identify blocking tasks? Not easily because it involves looking at the reverse relationship - if "1" depends on "2", then "2" is blocking "1", but "2" contains no metadata to that effect. This also involves walking the chain.- Dependencies imply that a tool can then be used to determine things like critical path.- Can a task depend on a project? Vice versa?Nice job with 2.9 everyone!
Thank you all for the suggestions. One thing in common in all of those (and also a sentiment that I share) is that the todo.txt is supposed to be simple. So,Message 1 of 9 , Apr 11, 2012View SourceThank you all for the suggestions.One thing in common in all of those (and also a sentiment that I share) is that the todo.txt is supposed to be simple.So, my next question to the community is:
How do you handle dependency among tasks in your daily workflow?
I say do this with +projects for instance: (C) Clean out the garage @home +SpringCleaning +CleanGarage Rent a storage unit @errand +CleanGarage Buy storageMessage 1 of 9 , Apr 11, 2012View SourceI say do this with +projects for instance:(C) Clean out the garage @home +SpringCleaning +CleanGarageRent a storage unit @errand +CleanGarageBuy storage unit @errand +CleanGarageOrganize into trash store and sell piles @home +CleanGarageHave a yard sale @home +CleanGarage +YardSale
This works just fine to organize your project where:
Having some fancy plugin to indent and auto-complete one task seems like overkill when you could use a sort and solve this without adding any complexity.On Wed, Apr 11, 2012 at 3:33 AM, Danilo Zanatta <dan.zanatta@...> wrote:
- +SpringCleaning is a parent project with many other items (not shown)
- "(C) Clean out the garage @home +SpringCleaning +CleanGarage" is a child of #1
- all other items with +CleanGarage are children of #2.
- "Have a yard sale @home +CleanGarage +YardSale" is also a child of a +YardSale project.
Thank you all for the suggestions.One thing in common in all of those (and also a sentiment that I share) is that the todo.txt is supposed to be simple.So, my next question to the community is:
How do you handle dependency among tasks in your daily workflow?
... I try to keep only actionable tasks in my todo.txt. If I need to capture a task that can t be completed right now because some other task is blocking it,Message 1 of 9 , Apr 11, 2012View SourceOn Wed, Apr 11, 2012 at 09:33:18AM +0200, Danilo Zanatta wrote:
>So, my next question to the community is:I try to keep only actionable tasks in my todo.txt. If I need to
>How do you handle dependency among tasks in your daily workflow?
capture a task that can't be completed right now because some other task
is blocking it, I'll either add it directly to tickler.txt ("todo.sh
addto tickler.txt task...") if I'm at my computer, or add it to todo.txt
via the Android client and move it later, typically during my end of day
As tickler tasks become unblocked, I move them back to todo.txt.
... Unfortunately, the task number is the obvious identifier (in the CLI). However, as long as you avoid auto-archiving, direct edits, and let the CLI do theMessage 1 of 9 , Apr 13, 2012View SourceOn 10-Apr-2012 17:23:42 -0400, Ed Blackman wrote:
> On Tue, Apr 10, 2012 at 02:22:49PM -0000, danilo77z77 wrote:Unfortunately, the task number is the obvious identifier (in the CLI). However,
>> I was wandering if someone has a solution to implement tasks dependency
>> using the todo.txt tools. I have the cli and the Android Touch
>> My goal is to mark a task as depending on another task and, eventually,
>> having an option to filter-out tasks that are not doable right now.
>>From then, it'd be good to have a counter of the tasks that are on hold
>> because they depend on a particular task and so on...
> [3 lines deleted]
> The first requirement is for a way to identify a task that other tasks
> depend on, and that a task depends on one or more other tasks. The task
> number doesn't work, since that changes with archive, and can change out
> of band with direct edits or changes on other platforms.
as long as you avoid auto-archiving, direct edits, and let the CLI do the
archiving (the Android client isn't able to do that yet, anyway), you can use
the task number, provided that you adapt it when archiving.
> [21 lines deleted]I have implemented such a system for myself. It consists of custom actions:
> Up to this point, this is all doable for the CLI version. Add a few
> custom actions to give a task an ID, mark tasks dependent on each other,
> and show dependent tasks. Add a display filter to filter out dependent
> tasks, and you're done.
wait, unwait, listblockers, lswait, blockerview, depview
and hooks into do and archive actions. It's probably best described by one of my
I don't use it extensively (I currently have 7 blocked tasks out of 400), but it
has proven helpful for me, as I mainly use a heavily customized CLI client, anyway.
> Implementing for the Android version is harder, because the todotxtTrue. I have brought this up before, and Gina has decreed  that simplicity
> format isn't open for the id: and dep: extensions (rightly, I think).
> But the Android code also doesn't have extension points that would allow
> someone to write a plugin that would add new task menu items for adding
> IDs and marking dependences, add a new view for seeing dependent tasks,
> and filtering the display to remove dependent tasks from the default
trumps extensibility (except for the CLI). It would be difficult to keep all
implementations of an extension compatible, anyway. So, any such extension
requires you to chiefly use the CLI.
-- regards, ingo