parallel flows in issue dashboard
Description
The issue board shows how the issues flow from one step to another. Mentally, one should always go from one step to the next, never going back, and possibly never skipping a step. Going from left to right is like a qualitative timeline. However, sometimes it may be useful to have parallel possibilities. For example:
- Putting an issue 'on-hold' and putting it back to 'coding' is not a left-to-right flow. It's more like putting the issue on another, parallel stream.
- The issue board of gitlab itself contains lists like 'UX', 'Frontend', 'Backend', 'API'. These are actually parallel flows: an issue usually doesn't flow from UX 'to' 'Frontend' to ... .
Proposal
Being able to make parallel flows, putting lists under each other, like this:
----------------------
| log | UX | done |
| | | |
| | | |
| |------| |
| |front | |
| | | |
| | | |
| |------| |
| | back | |
| | | |
| | | |
----------------------One goes from log to one of UX/front/back. Moving vertically between UX/front/back may make sense as well, but most of the time, I suppose it will be limited to 3 steps: log - UX/front/back - done.
or even better:
-----------------------------
| log | anal |coding| done |
| | | | |
| | | | |
| |-------------| |
| | on-hold | |
| | | |
| | | |
-----------------------------Here, the happy flow is log-analysis-coding-done. However, one might put an issue on hold during analysis or coding.