You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have named steps, we may want to rethink the serial workflow progress reporting a bit.
Let's take a workflow consisting of three named steps, e.g. prepare data, generate data, fit data, when each step consists of five, six, and seven commands progressively.
We could report progress by:
(A) counting steps e.g. 3 of 3
or by:
(B) counting commands e.g. 18 of 18.
Each has its pros/cons: in the former, we don't know at which command we are; in the latter, we don't know in which step we are.
One could imagine a combined approach:
(C) counting steps and commands e.g. "step 2 of 3 command 1 of 6"
although this may be too much granularity.
I guess if people take time to write workflow with named steps, then they are mostly interested to count by steps (the outer structure), with commands (the inner structure) being of "secondary" help only.
This also has an influence on partial workflow execution, e.g. "run gendata step" means running first two steps and all its 11 commands. Progress reporting might be probably enough.
If people don't use named steps, then reporting by commands as we do now seem natural.
This is just a note to muse about the best defaults, also regarding other supported workflow engines.
Now that we have named steps, we may want to rethink the serial workflow progress reporting a bit.
Let's take a workflow consisting of three named steps, e.g. prepare data, generate data, fit data, when each step consists of five, six, and seven commands progressively.
We could report progress by:
or by:
Each has its pros/cons: in the former, we don't know at which command we are; in the latter, we don't know in which step we are.
One could imagine a combined approach:
although this may be too much granularity.
I guess if people take time to write workflow with named steps, then they are mostly interested to count by steps (the outer structure), with commands (the inner structure) being of "secondary" help only.
This also has an influence on partial workflow execution, e.g. "run gendata step" means running first two steps and all its 11 commands. Progress reporting might be probably enough.
If people don't use named steps, then reporting by commands as we do now seem natural.
This is just a note to muse about the best defaults, also regarding other supported workflow engines.
(stemmed from reanahub/reana-demo-root6-roofit#32)
The text was updated successfully, but these errors were encountered: