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