Github Workflow for the group

[xilouris]

We need to establish a workflow to cater for monitoring and planning of group activities. Below you may find some main steps.

• Each EU project, research or internal activity is contained in a single Repository e.g. "OASEES Backlog"
• Every Repository is linked to the only project available in the github which is "CORE Backlog" - the later is used to observe the progress
• For each repository the leading person is responsible for the coordination and planning of sub-activities by introducing issues.
• Team Members is also possible to set their own issues, decomposing bigger ones to more concrete steps or proposing new ones.
• All issues need to provide initial information describing the problem or the objectives of the activities and foresee the time to be allocated for the issue.
• The communication is carried out through Slack (at the moment) and all changes and notifications are available at the #0-core-backlog-monitoring channel. You may even use the slack channel to provide quick comments and reactions on the ipublished events.

LANES

Under the only project in GitHub CORE Backlog you may find the following "lanes"

• New: For issues that are either conceptual at the moment or have not being discussed.
• Backlog: For issues that have been discussed and are assigned and missing being scheduled
• In progress: Yeap! this is the real thing, actual work planned and being executed
• In review: Well sometimes the work done needs to be reviewed and re-discussed. May spark new issues and additional planning.
• Blocked: Shit happens, when there issues are not progressing because of other factors and need to be re-scheduled or paused for a while
• Done: Hooray, work done, but is it ? The issues here remain open until the issuer (the team leader or the OP of the issue) closes it.

Roles

• Assigner/OP: Is the one that has created the issue and controls the lifecycle. He has total control over the issue lifecycle
• Assignee: Is the person that is responsible for the issue resolution. While the issue is "In Progress" he needs to make incremental updates on its status (weekly) or if the issue has subtasks update the issue while theses subtasks are done. He can mode the issue to "Blocked" or "Done" but he should not Close it.

Workflows

• The newly created issues initially are to appear as "New" at the Kan Ban of CORE Backlog
• When the details of the issue have been discussed the issue is moved to the Backlog and start/end dates as well as assignees are added
• When it is time to start working on the item (based on the scheduling) the issue is marked as "In Progress" by the person that has been assigned the task
• Issues that for some reason are no more active or are blocked are moved by the assignee in "Blocked" lane
• In case issues are ready to expire or they are falling behind they are moved by the Activity Leader to the "In Review" lane. We should not have more than 4 issues under review concurrently.
• When the issue has been addressed, the "Assignee" moves the issue to "Done" lane for review
• Following the review the Activity Leader closes the issue

Reporting

• The reporting is mandatory for running issues every 1 week (each Monday) and also reviewed during plenary group meeting bi-weekly
• Everytime an issue moves across lanes, a comment with justification needs to be accomodated
• Some issues may have incremental or descrete steps (e.g. checkboxes), in that case fast reporting can be done when a step has been completed