Re: Humane Tasking Initiative / FlowgencyTM

[RonW]

Interesting project.

As for Task Warrior, I think you are over thinking your 2 main problems.

1. The jump from one evening to the next morning just reflects the day's expected progress. It would be clearer if you did the position calculation in days, which you can get by calculating the start, end and current days from the start, end and current times.

   If you want hourly resolution, multiply the difference in days, and the scheduled number of days by the number of working hours per day. then calculate the current working hour from the current time:

   $workHr = $currentHr - $startHr;
   $workHr = $maxWorkHr if $workHr > $maxWorkHr;
   

   Either way, you get jumps. But by using days (or work hours), you get consistent jumps, reflecting the current day's (or hour's) goal.

2. This is really a matter of planning a reasonable set of subtasks for each task. As long as the tool (Task Warrior or yours or other tool) supports subtasks, you can work around it.

That said, your description of the second problem includes the solution for submitting a feature request: divide the feature in to sub features.

So, first submit a request for a feature to estimate task progress by the number of sub tasks completed. When that is completed, submit a new request to enhance the task completion estimate by summing the scheduled days for each completed subtask, then divide by the sum of the scheduled days for each subtask. After that, a request to enhance resolution from days to working hours.

Then you could consider a request to calculate the urgency of each task by comparing estimated progress to expected progress.

Each of the above 4 requests could be described in 2 sentences and 1 to 3 formulae. And as long as you submit the requests one at a time, they are (probably) not overwhelming.

[flowdy]

Hi RonW,

thanks for your feedback.

By your first point you seem to suppose that every day is a work day, and everyone is like the other in these terms. But there are also week-ends, and holidays too, which cannot be foreseen, which is again why that must be implemented in a configurable way. The same for working hours. Not all days comply to a $maxWorkHr standard, again mind the week-ends or, say, the one part of the week it is you who attends the kids, the other one your wife. You could have even distinguished your planning on the basis of even and odd week numbers or whatever interval.

At last, you may certainly find I have overthought that stuff. However, otherwise I do not want to risk that a distributed time feature thought that simple is only usable by few, discriminating others because they are not willing to adapt their job life to how I suppose humane work has to be. Clearly there is a trade-off in simplicity, I hope not too much.

What concerns your second point, yes. Subtasks may roughly achieve what I got in mind. OTOH, by simply linking tasks in terms of parent and child tasks, you are bound to filling in the mandatory fields like priority level or (modifiable) due-date even for the innerst, most simple, atomic tasks. I don't know if that would motivate to structure tasks. Taskwarrior terms are likewise projects, subprojects and atomic tasks, whereas FlowgencyTM has tasks and (sub(sub-...)-)steps, with tasks in fact being "main" steps associated with a user, and general other mandatory details as mentioned above. Mind the similarity.

So, I am rather skeptical if a number of independent feature requests would have been appropriate given an integrated complex conception in mind.

-- flowdy.

[RonW]

I am quite aware of weekends, holiday days and other planned time off. And I would expect a tool like Task Warrior to already incorporate all that - including being able to configure planned time off and configuring available work hours per work day. If that's not the case, then I'd say TW has a long way to go to become useful to the Project Managers I've worked with over many years.

Tasks, by whatever name they are called, should be arbitrarily subtask-able. A task with no subtasks would ideally be small enough to treat as either done or not. In reality, there are tasks that are large enough to need progress tracking, but are impractical to further subdivide. Or if are subdivisible, involve open-ended iteration to complete. Those tasks will be stuck with "airy" estimates. (The best tool for dealing with airy estimates is evidence based estimation.)

"Atomic Steps" are a convenience that can be simulated by "calculating" reasonable "default" values for the various fields. The simplest case being to insert special values that would not be accepted from the users. Otherwise, some fields would inherit the values from the parent task. Other fields can be derived. In one tracking system I used, it is possible to creating sibling tasks to the task currently being viewed. A new sibling could be either a predecessor or successor. Then, based on the effort estimate for each of the siblings, their due dates were automatically calculated from the parent's due date. And the effort estimate propagated to ancestral tasks, both to keep the ancestors updated and to generate warnings about potential schedule slip.

Anyway, good luck with your project.