Define standard for github project kanbans

[jgvictores]

Define standard for github project kanbans.

Additionally specify if any specific project will have a different structure.

Personal thoughts which lead to no specific direction:

• The current device I use most renders 4 columns at normal zoom without horizontal scrolling.
• From the HORUS project description here we see an indication to exclude low-priority (could also be for ideas). Is this a good idea? We'll speak about it!
• We could also add a limit to the Done column, such as "archive when reaches 10"

[jgvictores]

Some things commented with @David-Estevez (very related to #76)

1. For columns, we define the basics (please preserve the first 4 and in that order!), but new can be added per repo.
2. The chosen ones are:
   1. To do
   2. Blocked
   3. Waiting for 3rd party :tada:
   4. In progress
   5. Done

[jgvictores]

PD: it is generally recommended to keep priority: low and priority: idea out of the kanban (as a general rule of thumb; can be different if low population).

[jgvictores]

Just some ideas from different projects: i. Receiving feedback / opinions ii. Tracking / continuous tasks

This is just for traceability. E.g. We may, in fact, even end up deciding something like "hey, there should not even be tracking/continuous issues".

[jgvictores]

Pending thing we spoke about:

• [ ] Define project owners
• [ ] Document at https://github.com/roboticslab-uc3m/developer-manual where to document this (e.g. on https://github.com/roboticslab-uc3m/developer-manual vs directly on project description vs etc)

[jgvictores]

Additional note: For handling blocked/blocking issues, it seems like the ideal solution would neither be labels (see #76) nor project columns, but instead a dependency tree. :smile:

[jgvictores]

Added section at https://github.com/roboticslab-uc3m/developer-manual/commit/35e36711c6f1bcd30d0de5cb9855b3b4591a85c5

[jgvictores]

Closing due to inactivity. Never arrived to a best solution here, imho.