Task naming conventions (as a producer and/or artist)

I’m curious what approaches to task naming people use out in the wild.

I’m working on a config where the studio tends to have a “main” task for each pipeline step. If multiple artists are required to work on a single task (eg switching artists out over time) then a new task is created also called “main”, thus allowing for production to more easily track the scheduling of tasks on a per-user basis.
(the artists typically work on a file named “main” also, that matches the task-name, and continues version-incrementing from one task to the next)
Is this a common approach?

This illustrates the current typical workflow.
Initial task setup, for first artist.

  • step: comp, task: main(id:123), filename: main_v001.nk
    then a new artist starts, production makes a new main task (id 124), then the artist picks up from the previous artist main_v001.nk.
  • step: comp, task: main(id:124), filename: main_v002.nk
    then later, production might make another comp step task called “finish”, and the artist would pick up from main_v002.nk, and publish main_v003.nk from task: finish.
  • step: comp, task: finish(id:125), filename: main_v003.nk

What other common patterns are there to task naming? eg naming the main file and main task the pipeline step?

I always thought the logical approach would be to name the project file after the task-name, but I also appreciate this makes it unclear which file is the most up to date within a single pipeline step folder.

Penny for your thoughts!

Hi Patrick,

I’ve always found that there needs to be some flexibility around task names. Pipeline steps should do the majority of the heavy lifting when it comes to file organization but initial tasks usually are best named around how bids are broken down and how projects are setup to handle the work with the artists.
For example on a larger project, some tasks may need to be split right from the get go due to multiple artists or vendors in a way that allow for coherent scheduling. Sometimes tasks need to be broken down to handle different elements within a step or for small/fast projects drastically simplified to make life easier for a generalist doing a lot of work without the need to be micro managed and simplify the scheduling demands.
If a studio is leveraging the resource management side of things then task organization can play into that as well since you can’t use the split options to feed that data correctly (at least the last time I checked that was the case).
Personally I always avoid multiple artists being assigned to the same task so having new tasks created when work is reassigned so I 100% agree with your logic there. Ideally there should be some consistent logic around task naming for each step but my belief is that the names should need to make sense for the scope of work. Anyone should be able to look at the task names and have a reasonable understanding of the work that is to be done while the descriptions hold the general details.
From a pipeline perspective, consistency makes things a lot easier but the nature of tasks is that pipeline steps are those locked in terms and tasks are based on the production management needs which can vary.

1 Like

Thanks Pete, very nicely put.
My only gripe with this currently is the naming of a task(s) “Main” for a given pipeline step. In the SG Workfiles under the MyTasks tab, you end up with a list of “Main” tasks with little to indicate the actual work required. I have added the visibility of additional fields (eg the step shortcode) but it’s quite clunky looking.
You also end up having multiple same-named tasks in the entity tab hierarchy in workfiles that point to the same files on disk (assuming you don’t filter by assignee on these tabs). A little confusing in that depending on which task you open the file from, determines which task any Versions/Published files will be assigned to. It seems artists could end up publishing against another artists “main” task.
That being said, perhaps this is the lesser of two evils, in a generalist-centric approach, the artist will just want to work on a single file whilst jumping between SG Tasks of the same step, and this is the best way to achieve it.

Yeah, tasks with the same name might require some additional work so that when artists are saving or even launching into a task they only see the ones assigned to them. But you would have to disable the default save options within the software being used. I guess its just a matter of preference and how “locked down” the ecosystem is

Interesting indeed to discuss workflow and best practices!

We’ve chosen a different approach:

  • by default, task name is equivalent to pipeline_step (Step: comp, Task: comp)
  • in case of multiple tasks in the same pipeline step, to be able to split the work and assign to multiple artists, we add a capital letter (Step: comp, Task: compA, Task: CompB). We also avoid multiple persons on a single task.
  • default workfile name follows the same rule : 001-010_comp(A|B|C)_v001.nk. The same name will also be used for the review version. This means that from a workfile or a version, we are able to deduce all the info we need: shot, step, task.
  • default naming convention are automatically applied by the Shotgun loop.

This solution is working well for us and is really consistent.
It’s quite straightforward and easy to understand for new members.
We avoid having same filename across different tasks / steps to avoid error potential overrides / errors.

1 Like