This was the task dependency diagram for yesterday evening. So, so long ago, Rollie was talking about task tracker design, and I didn’t let my being uninformed stop me from being opinionated. But for the record, my dream task tracker would do/look something like this. Sorry that it’s too big for Wordpress:
(click to enlarge)
Nice work on the diagram, dude. I always appreciate a well-done unnecessarily illegible diagram. (See my blog posts from History.)
A couple of questions…
Does the task tracking service generate the graph for you? If so, what does the input UI look like? If not, what does it actually do? And either way, how do you interact with the service?
What’s “WHY NOT” mean?
Well that’s actually enough for now.
Comment by ejucovy on December 1, 2007 at 10:51 am
I wrote a response to this last night, but Firefox crashed before I could submit it. Here it goes again:
– Does the task tracking service generate the graph for you? –
Probably, but not necessarily.
I didn’t give the proper backstory for this post. On Thursday I was sitting there frustrated because I couldn’t figure out what to do with my time. One by one, I thought of things I had to do, and each one was blocked by some circumstance over which I felt like I didn’t have control.
After a while I realized I was actually looping over the same tasks over and over again, so I started graphing out the dependencies on paper so that I could get a clearer picture of what was going on. And it was only after I graphed out a lot of the workflow that I realized that the blog post that Cholmes had asked me to write about the WMS Reflector didn’t have any dependencies and so I could work on it right then.
Later, after I had gotten as far as I could on the WMS Reflector post, I got worried because it looked like everything else had a dependency. But looking at what my work depended on, I saw that a big, high-priority thing for me depended on an essentially trivial task from Cholmes. The maximum global payoff would come from nagging Cholmes first, and now I’ve got plenty of work to do.
Back to your question: yes, a task tracking service could generate the graph. But more importantly, I think, the underlying representation of tasks relations should be graphical like this, because it makes it easy to query that representation for important task-related questions like “What should I do right now?” or “Who should I nag?”
– If so, what does the input UI look like? –
Not sure. I see two ways to go, but there are probably better ones:
The first would just be essentially like trac except with some extra fields. When I was one-by-one adding tasks to my pen-and-paper graph, I didn’t have the whole picture in mind when I added each one, just pairwise relations between tasks (or, really, tasks and situations–see below).
The second way to do it might be more graphics intensive: one could try to let users literally draw out a graph, sort of like how I drew this graph using Dia. I imagine this would be really hard to get right, since a large, collaborative project could have an enormous graph structure that would be unwieldy to work with.
A middle way: allow the user to input a task with a simple, trac-like interface, but assist the user in laying out the dependencies by dynamically generating and displaying the immediately relevant subgraph of the task.
– And either way, how do you interact with the service? –
Kind of like trac, I guess, except that in addition to adding tasks and viewing them, you can (maybe) visualize it as a graph and (definitely) ask it things like “What unblocked tasks do I have?”
It’s more a question of what’s going on under the hood. Like, with a graph structure like this, you could concieve of the *priority* of a task depending not only on the priority assigned to it by the user, but also on the priority of tasks that depend on it. Or you could have it detect cycles in cases where two people are just waiting on each other to get something done. Or you could note when a particular situation (see below) is time-dependent and have that factor into the logic that resolves the query.
– What’s “WHY NOT” mean? –
Yeah, so this is what neither trac nor the current task tracker has but which I think is kind of needed for this to make task-related decisions for you.
The things I labeled as “WHY NOT” aren’t tasks. They were facts about the world that were the reasons why I couldn’t proceed with certain tasks. It wasn’t a very good name, because they were only ‘why not’s in relation to the tasks that depended on them. To other tasks, they were the things that tasks were going to change in the world.
So, rather than thinking that task A depends on task B, I was thinking that task A depends on some state of the world X. How do we make X come about? With task B.
I’ve referred to things I labeled as “why not” as “situations” above, which is language I’m not thrilled about. But I think there’s a lot of benefit to thinking about task organizing in terms of an additional category of stuff. The first is that grounds tasks in some sort of goal which isn’t the task itself. Ideally, I would flesh out the graph so that each of my TO DO tasks had an arrow to some goal. “Community Almanac RFP” could then have been as task with the purpose of “Geoserver has the Orston Family Grant.” This would be a “WHY” instead of a “WHY NOT,” but you’ll notice that for tasks that depend on situations, there is a WHY/WHY-NOT side to each situation. “Artios Rejects Getlog Requests” was the reason WHY NOT that blocked progress on the “History Feed.” But NOT(”Artois Rejects Getlog Requests”) is a reason WHY Arne needs to “Fix Artois’ Geoserver.”
I think there’s a lot of power that comes out of this approach. For example, it allows you to set the priority of _goals_, instead of tasks, but then allow you to creatively come up with many ways to achieve that goal. If a goal is met by one of those means, then the task tracker could algorithmically determine which tasks were no longer necessary (because they were assigned to solve a problem that’s already been fixed).
Does that answer your questions?
Comment by sbenthall on December 3, 2007 at 11:33 am
(I added a smaller diagram with a link to the larger one)
Comment by nickyg on December 3, 2007 at 12:10 pm
Thanks Nick. Sorry about that–I’ll be more responsible in my image posting in the future.
Comment by sbenthall on December 3, 2007 at 12:14 pm