Skip to content

Project planning with Github project board tutorial meeting

Jump to bottom
Caspar van Leeuwen edited this page Apr 14, 2023 · 1 revision

Project planning meeting (2023-04-14)

Attendees

  • Kenneth Hoste (HPC-UGent)
  • Elisabeth Orteage (HPCNow!)
  • Neja Šamec (NIC)
  • Caspar van Leeuwen (SURF)
  • Matej Praprotnik (NIC)
  • Antonio Sciarappa (Leonardo)
  • Thomas Röblitz (UiB)

Agenda

  • TODO at start: RECORD MEETING

  • adding GitHub accounts to MultiXscale organisation

  • overview of labels (WP*, D*, T*)

    • give at least one person per WP write permissions so they can add/edit labels

  • walk through creating of an issue + adding to a project board

  • demonstrate moving of issues in project board timeline

  • use the project boards as guide for montly sync meetings!

    • task views during meetings
    • deliverable view close to due date for deliverables

  • one single project board for WP2+3+4 vs separate for WP2, WP3, WP4?

    • Need to take a decision before filling it with issues: if we split later, all existing issues will be associated with all project boards, and you'll have to remove each project from the issue manually.

  • TODO: project boards for WP6 + WP7 + WP8

Notes

  • Tutorial: Kenneth goes through https://github.com/multixscale/planning/blob/main/README.md

    • Meeting is recorded for those who couldn't join today.
    • Red line on the board = current date. It can be helpful in your monthly WP progress meeting to go check if all tasks 'left' of the red line are indeed finished (they should be), and whether all tasks that intersect the red line are actively worked on (again, they should be). You can modify start/end dates whenever this is appropriate. E.g. if a task was planned to start, but hasn't, you can agree within the WP on a new start date and move it.

  • Thomas: Can you visualise dependencies?

  • Thomas: What does the 'graph' (insights) button do on the board?

    • We haven't played with this. It shows how many tasks are in a certain status (open, in progress, closed, etc). There might be more possible, we can experiment in the future

  • Matej: we can maybe automate part of generating the deliverables, e.g. allready put some titles or bullet points based on the information on GitHub

    • Kenneth: we can look at it, but it might be a bit involved to get all the information 'out'

  • Caspar: note that the labels are very short abbreviations of the task & deliverable titles in the proposal. If the abbreviations are confusing / not clear, we can easily modify them, so please let us know.

  • Kenneth goes through example of creating a new issue from https://github.com/multixscale/planning/blob/main/README.md

    • Note that tickets are listed on the board, but don't show a timeline unless you set a start and end date to it.

  • Kenneth: one question from our side, would you prefer a combined board for 2-4, or separate ones per WP?

    • Upside of separate boards: less tabs
    • Downside of separate boards: no combined overview of WP 2-4 issues.
    • Probably makes most sense to combine those WPs that might have joined meetings, so they can look at a board that shows all of them.

  • Kenneth: the boards will only be useful if they are actively used. If you ignore setting proper labels, start/end dates, etc for a few months, you'll never catch up again.

    • There maybe a role for the steering committee here too, to 'enforce' this useage, as it also provides a live overview of the status of the project to the steering committee.

  • Kenneth: note that you can also link to external tickets, from other repositories. See e.g. https://github.com/multixscale/planning/issues/16 which links to the EESSI repository. This will probably also be useful for e.g. ESPResSo development, which will probably mostly be done in their own github. They can then easily create such a 'parent' task in the MultiXscale repository to keep an overview of all activities

  • Off topic: we still need to make sure to organize a landing page in the Github repo. We can then link to e.g. the shared storage, where we will put the recording of this tutorial.

Clone this wiki locally