In which case the topic equals hulk seq01 1000 animation. A user is then assigned to this task via configuration, similar to how templates are assigned to their items in the inventory.
hulk/users.yaml
marcus:
- bruce modeling
- greenBruce modeling
thomas:
- bruce rigging
peter:
- seq03 1500 animation
The top-most topic is discarded as it would always be the name of the project.
logic
If no users.yaml is present, an artist could enter any given project at any given item under any given task as usual.
$ be in hulk seq05 3500 animation --enter
No development directory found. Create? [Y/n]:
When users.yaml is present within the project, a user may only enter tasks to which he has been assigned.
$ be in hulk seq05 3500 animation --enter
You have not been assigned this task, aborting..
benefits
Why bother with tasks in be?
Production can control who works on what
Users can list their tasks
$ be for marcus
- seq05 3500 animation
- AngryBruce rigging
- AngryBruce lookdev
limitations
What is it about tasks in general that couldn't be facilitated using this approach? For example, is it ever necessary, or part of be's responsibility to provide per-user environments? This can be hard to fit into this particular implementation, but is it ever necessary or are there workarounds?
goal
Manage users and tasks via
be.implementation
A
taskis represented by a fully qualified topic.In which case the topic equals
hulk seq01 1000 animation. A user is then assigned to this task via configuration, similar to how templates are assigned to their items in the inventory.hulk/users.yaml
The top-most topic is discarded as it would always be the name of the project.
logic
If no
users.yamlis present, an artist could enter any given project at any given item under any given task as usual.When
users.yamlis present within the project, a user may only enter tasks to which he has been assigned.benefits
Why bother with tasks in
be?limitations
What is it about tasks in general that couldn't be facilitated using this approach? For example, is it ever necessary, or part of
be's responsibility to provide per-user environments? This can be hard to fit into this particular implementation, but is it ever necessary or are there workarounds?