panoptes
panoptes copied to clipboard
Should Workflow Version also track changes to Steps?
Discussion & Possible Feature Request
Question: should a workflow's version
attribute also keep track of changes to that WF's steps
? Currently, the version only keeps track of changes to the workflow's tasks
.
My current understanding:
-
Assumed purpose: a workflow's version (e.g.
exampleWorkflow.version = '12.345'
means major version 12, minor version 345) is used by project owners to keep track of which version of the WF (and its questions) that volunteers saw when they submit their classifications. - The major version number is incremented by 1 every time...
- A new Task is added to
workflow.tasks
- A Task is removed from
workflow.tasks
- A Task's
task.next
is changed (i.e. flow of the WF is changed) - A branching ('single'-type) Task's answer's
task.answers[x].next is changed
. (i.e. flow of the WF is changed) -
workflow.first_task
is changed. ~~(untested) ...whenworkflow.first_task
is changed...? Probably? (TODO: Shaun, test this and confirm.)~~ (Update: yup)
- A new Task is added to
- The minor version number is incremented by 1 every time...
- Any attribute within a Task is edited. (e.g. change
task.question
for "Do you see a cat?" to "Do you see any feline?") - ...except for
task.next
ortask.answers[x].next
, which triggers a major version bump.
- Any attribute within a Task is edited. (e.g. change
- ❗ No version changes are observed when the Steps are changed.
Dev Notes
The complication:
- The new Pages Editor on PFE introduces the concept of organising Tasks into Steps (aka Pages) to project owners.
- Link: example staging WF in the Pages Editor. (Please ping Shaun/Sam/Sean before editing, and for any questions.)
- In certain cases, a workflow can be modified without adjusting the version, which defeats the assumed purpose of the workflow version.
- e.g. rearranging workflow Steps/Pages doesn't cause a version bump.
- Note: in most cases however, the Pages Editor will create/delete Tasks alongside creating/deleting Steps, so this problem was masked for a long time.
Testing:
- Open the link above.
- Add a Task (which also adds a Step/Page at the same time). Observe that the major version number increases as expected (because a Task was added.)
- Edit that Task T0 in Step/Page P0, by changing its main question or instruction. Observe that the minor version increases as expected
- Add another Task in another Step/Page, so you have at least 2 pages.
- Rearrange the pages (either via drag & drop, or the sorting arrows). Observe that no version changes happen, which isn't expected. (Examining the workflow resource will show that workflow.tasks remains unchanged, while workflow.steps was updated.)
Thoughts:
- The major version number also should increment when...
- A new Step is added to
workflow.steps
- A Step is removed to
workflow.steps
- A Step's
step.next
is changed (or more accurately,step[1].next
, due to the nesting arrays) - The order of Steps in
workflow.steps
is changed.
- A new Step is added to
- ❔ I'm not sure if it's the major OR minor version that should change when...
- A Task is added to a Step. e.g.
workflow = { tasks: { T1 }, steps: [ [ 'S1', { taskKeys: [ 'T1' ] } ] ] }
==>workflow = { tasks: { T1, T2 }, steps: [ [ 'S1', { taskKeys: [ 'T1', 'T2' ] } ] ] }
- (As mentioned, a Task is created at the same as a Step on the frontend, so in practice it'll still trigger a major update in practice.)
- A Task is removed a Step.
- The order of Tasks in a Step is changed.
- A Task is added to a Step. e.g.
Status
This will eventually affect project owners when the Pages Editor is more widely adopted, but for now there's still time for discussion.
I think the first thing that needs to be done is for someone with more knowledge to check my assumptions, especially (1) the assumed purpose of the workflow version, and (2) whether the major & minor versions are being incremented (and not) as I described.