Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Humane Tasking Initiative / FlowgencyTM

by flowdy (Scribe)
on Feb 20, 2016 at 13:11 UTC ( #1155702=perlmeditation: print w/replies, xml ) Need Help??

There is a plenty of software tools of that kind to be discovered online. Either free or for charge, implemented as a webservice or installed locally, command line or graphical, large enterprise-scale project management or simple todo listers for individual use. Lots and lots of stuff like that.

A couple of years ago I very considered using a tool called taskwarrior. I tested it. Liked the multidimensional concept of urgency. I could not help hesitating. Pondering on it, I finally found out what bugs me in regard to urgency calculation that is relevant for the ranking of my to-dos.

I would have liked to configure an urgency criterion "drift between task progress and passage of time". So urgency is determined, with the respective configured weight, by how much I have already proceeded with the task in relation to the elapsed and the available time.

As I cannot code C++, just have a little command of that language, I started to make a feature request for the taskwarrior devs. Soon then I was stuck because I realized it would not be easily feasible. Two major problems needed to be addressed so such a feature would make sense actually:

  1. Calculation of the position on the scale between starting date and due-date goes like this: my $pos = (time() - $start_time) / ($due_time - $start_time).
    A problem showed up when I elaborated the idea in my mind: The due-date is like every other date for a system, nothing more than the number of a second counted since epoch, i.e. Jan 1st, 1970 01:00 on Unix and unixoid systems.
    Computer systems do not sleep. Well, they might be turned off at night. But when turned on again, they re-initialize their time with the battery-based hardware clock, so for software, shutdown is as intangible as death for living creatures.
    But for us humans it is a crucial difference in life quality whether we get regular and sound sleep or not. With naive time calculation as described, chances are we spend the night with thoughts drawing circles in the mind like ... My tool expects me to work day and night, like now for example, but I sleep or at least try to, for sure I will fail my deadlines, oh. Oh wait, I remember my tool said I achieved 39% although only 22% where expected, so all is fine ... but tomorrow it will expect me to have achieved 71% or so, oh that glorious a tool, computers are in fact so inhumane ... I should stop using the tool that steals my sleep and ranks my tasks in such an irrealistic way.
  2. My progress should not simply be an input labelled "Estimate progress (%)" because that would be prone to airy manipulation, but in fact be calculated from which steps and maybe substeps of a task I have already checked and which not yet. In order to shape progress more realistically, we need to consider optional indications like "step A be about twice the expenditure of time for step B".

In the end, I dropped my idea of writing feature request. There is no use to get frustrated by a reply like "uh, tl;dr, could you make a pull request, thx", this at least would be my reaction when faced with a load of pages for a feature request. Rather, I started my own open-source project in Perl. There are great CPAN modules like Moose, DBIx::Class and Mojolicious, so I was sure it is feasible once I get through the elaboration of the time problem. Computer-aided task and time management aligned to individual biorhythm and job conditions, this was and still is my objective. And I got through it. The time model related code is even fairly covered by tests and it works practically, reduced my work-related distress in my "life" time, I have been testing it in my every-day work for more than a year (service administration, software development with Perl).

Because my mid-of-scale, yet another but the better ;) project is written in Perl, I advertise it here in the PerlMonks community. Learn more, and if you are interested, be welcome to test the online demo installation at my Humane Tasking Initiative site. Or read on, clone or fork my FlowgencyTM code repository at GitHub.

Contributions, questions and comments are welcome. Please understand that the tool must remain far from supporting staff performance monitoring. Technically, it can easily be abused like that, like a kitchen knife can be abused for murder. This is why I envision the software project be embedded in an initiative, and why local usage with full own data souvereignty is focussed in development.

To those who find that concept of time overhead I recommend TaskWarrior instead. Between that project and mine can be found a remarkable number of similarities, no wonder because TaskWarrior is my primary source of inspiration. I guess admittingly that the development of Taskwarrior is more stable than the development of FlowgencyTM (by the way, this is a working title subject to change in the future), because I am the initiator and main developer, the only one as yet, whose full-time job deserves priority.

Replies are listed 'Best First'.
Re: Humane Tasking Initiative / FlowgencyTM
by RonW (Parson) on Feb 24, 2016 at 00:59 UTC

    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.

      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.

        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.

Re: Humane Tasking Initiative / FlowgencyTM
by pbeckingham (Parson) on Feb 24, 2016 at 17:29 UTC

    Taskwarrior dev here.

    When we receive feature requests, it's more likely that the response is "please tell us more", than "uh, tl;dr, could you make a pull request, thx". Particularly as we don't work from pull requests. In fact, I feel like we spend all our time asking for more details from both feature requests and bug reports.

    But I like your idea, and I wish you had made that feature request. This seems like an interesting improvement to urgency, and anything that truly improves the handling of lists is fair game.

    I like the non-linear ramp up as the due date approaches. Do you cap the number? Otherwise it seems that other urgency factors will be drowned out.

    I agree about the "Estimate progress", which is only prone to manipulation as you said, but also omission. Any data that is collected, and simply shown back to the user isn't really pulling it's own weight.

      Cool, nice to meet you here!
      Do you cap the number?

      Sorry, what do you mean? The number of urgency criteria is five by now, and except priority all are time-dynamic i.e. influenced by progress of the defined "net working times" vs. still times.

      I invite you to take the code relating to the time model as the feature request. Given your perlmonk rank, I suppose your practical knowledge of Perl is better than mine of C++. You may ignore the rest, taskwarrior is appreciated as it is. My time model implementation is not yet perfect, for sure, but it is pretty complete.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1155702]
Approved by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2022-01-27 07:54 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (70 votes). Check out past polls.