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.