Three ways to assign people in Taskjuggler

Taskjuggler is a powerful project management tool with many advanced features. But one of the most basic functions of a project management tool is assigning and scheduling tasks. Depending on how you’re working, there are three ways to assign people to tasks in a Taskjuggler project.

allocate

In some ways, the allocate keyword is the most straightforward approach. allocate assigns a person (or multiple people) to a task. It takes into account the task’s effort when scheduling tasks. It assumes each person is devoted to that task until it is complete (there are ways to get cute with it, but for now we’ll ignore those).

To allocate someone to the task, you first need to define them as a resource. I’m not a fan of calling people “resources”, but it works out in this case. A resource can be more than just a person. I’ve used “oven at 350°F” and “oven at 400°F” as resources when using Taskjuggler to schedule Thanksgiving dinner prep. (Yes, I realize what this says about me.)

The sample project snippet below demonstrates a simple use of allocate.

resource aexample "Ann Example" { }

task something "Some task" {
    effort 4h
    allocate aexample
}

You might have noticed a problem: allocate is built on the assumption that people have predictable schedules and time. This assumption is often valid in a corporate project, but is rarely the case in an open source project. Volunteer contributors come and go subject to the dictates of their jobs, family lives, etc. — and often with no warning.

responsible

responsible is similar to allocate, except that it has no impact on scheduling. This makes it easier to work with things that are time-based and not effort-based. For example, as my colleague and I work on the Fedora Linux 37 Release Party plans, I use responsible to indicate which of us are going to work on a particular task. The tasks generally involve a lot of waiting, so this model works a lot better. Recruiting presenters isn’t three weeks of effort, it’s a lot of short-effort bursts over three weeks.

You can also use responsible to indicate who is accountable for a task. Confusingly, the allocated resource would be responsible in the “RACI chart” sense.

Like allocate, you have to define a resource before you can set them to be responsible. The sample project snippet below demonstrates a simple use of responsible.

resource aexample "Ann Example" { }

task something "Some task" {
    duration 4h
    responsible aexample
}

flags

The final option is to use flags. Unlike allocate and responsible, flags does not require you to define a resource. Instead, you define a a flag, which has no additional attributes. This makes flags very flexible. You can use them to refer to people, concepts (e.g. “critical path”), or meta information (e.g. “hidden”). However, you can’t give more readable labels to the flag. For example, there’s no way to display the “aexample” flag as “Ann Example”, the way you can with a resource.

The flexibility of flags can also make them confusing. If you use flags to indicate both individuals and functional areas within the project, report output becomes noisy.

For this reason, you should probably avoid using flags to assign tasks to people. However, it can work well for a project plan that contains milestones for teams. Older Fedora Linux schedules used flags to generate team-specific task lists from the main release schedule.

The sample project snippet below demonstrates a simple use of flags.

flags aexample

task something "Some task" {
    duration 4h
    flags aexample
}

This post’s featured image by Alvaro Reyes on Unsplash

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share