Skip to content

Meeting 2026-08-18

  • Should we have another host? NAISS, NBIS, CodeRefinery?
  • Decide later, we all seem positive to CodeRefinery, we ask Diana Iusan if we fit the CodeRefinery style
  • Staying at UPPMAX seems fine too
  • Should we transfer the repo to https://github.com/NAISS-Training?.
  • Pro: it is clear in the name that this repo belongs to NAISS
  • Con: when we need to get permission (e.g. requesting a DOI from Zenodo), we need to ask, where UPPMAX may be (even) more helpful than NAISS

  • Votes: [DECIDED: KEEP URL AS IT IS]

    • B: NAISS if we do more HPC, NBIS/SLL is too biology-only. Or CodeRefinery?
    • M: if we see it as a NAISS course, or is it an UPP
    • R: Against. Keep the repo where it is, as it does not benefit teaching to change URL.

  • Should the course be script-first or package-first?:

  • Pro (for script-first): we can reduce the course content
  • Con (for script-first): the deliverable gives us less to teach about

  • Votes: [DECIDED: scripts and dependencies]

    • RB: Script first, as there is no literature that recommends using a package (unlike in R).
    • ML: packages
    • [DECIDED] BC: scripts and dependencies

  • Should we publish the Zoom URL in private repository?:

  • Pro (to do so): we are sure that learners have a GitHub account and we do not need to disrupt our lessons fixing this
  • Con (to do so): some people will not prepare in time and be late

  • Votes [DECIDED: YES]:

    • RB: yes, as this rewards the people that do prepare
    • ML: yes
    • BC: yes

  • Should we invite more teachers?

  • Pro (to do so): we need to prepare less ourselves, we may change our efforts from teaching to coaching teachers
  • Con (to do so): more people requires more organisation

  • Votes [DECISION: WE WILL TRY THIS OUT]:

    • RB: yes. I suggest to invite former course participants. I am willing to formally mentor/coach each of these. I am willing to do the communication with them. I have already found 3 people willing.
    • ML: use experts from other organisations

  • Do want administrative support? Yes

  • Look which support is available, e.g. administration,

    • UPPMAX with Anders Sjölander: ML checks
    • CodeRefinery: ML talks to Diana
    • NAISS: we know this :-)

  • How to evaluate?

  • Option 1: use Retrospect as we do now
    • Pro: it has been done, no preparation needed
    • Con: Does this follow the literature?
  • Option 2: use a formal Retrospect, as recommended by the literature
    • Pro: Follow the Retrospect as used in the industry
    • Con: someone needs to find out how this goes
  • [DECIDED] Option 3: anonymouse evaluation forms of 1 open question: 'How would you improve the course?' daily and optional
    • Pro: anonymous, more critical, expected sharper/more_useful results
    • Con: can be too direct
  • Other options?

  • Vote:

    • RB: Option 3, or option 2

  • What is the course goal?

  • Option 1: the current course goal: it was decided to be 'Give an understanding of formal principles of software development'
    • Pro: it is what we have
    • Con: it mismatches with how we teach: teaching at the (Bloom) 'Understand' level does not call for a project to Apply it, hence RB suggested to discuss with the team to remove the project. However, the team decided to keep it. This means that we teach at the 'Apply' level, even though the course goal states the 'Understand' level

  • [DECIDED] Option 2: Apply formal principles of software development

    • Pro: it is the (Bloom) level at which we teach
    • Con: it is a change

  • Discussion: What are formal principles of software development that we aim to teach? SOLID? Separation of Concerns? Readability is important? Or is "formal principles of software development" shorthand for "computer science that we think domain scientists with scripting experience would benefit from"? Marcus thinks the latter is not unreasonable.

    • RB:
    • I like the alternative suggestion! I would agree with a slight tweak: 'the evidence-based best practices that we think domain scientists with scripting experience would benefit from during the course project'
    • which principles: those principles that can be found in books and/or academic papers, e.g. [Wilson et al., 2014][Wilson et al., 2017]. I use and teach those principles. You can find many references to the literature in my sessions, e.g. here
    • which principles we actually select to teach: I agree this is harder. I pick those principles that I can apply in the course project, leaving out those for which there is no time
    • why: the idea is to not to be able to make stuff up. It is all to easy to make stuff up.
  • Other options?

  • Vote:

    • RB: Option 2 or any option in which the goal and how we teach matches

  • How often should the course run?

  • Option 1: once a year
    • Pro: less often
    • Con: less often
  • [DECIDED] Option 2: twice a year
    • Pro: just as often
    • Con: often

  • Votes:

    • RB: twice a year. For me, PF is the course to try things out. As a teacher I need such a place to grow. I volunteer to teach the whole course once a year if other teachers cannot or do not want to.

  • How many hours for our guest teachers?

  • SKIP

  • Prerequisites

  • Add git as a must: add commit push pull clone from command line

  • We keep teaching the branching: checkout merge and Pull Request
  • We see how often this is read :-)

Next time:

  • When?
  • ASK for input?

References

  • [Wilson et al., 2014] Wilson, Greg, et al. "Best practices for scientific computing." PLoS biology 12.1 (2014): e1001745.
  • [Wilson et al., 2017] Wilson, Greg, et al. "Good enough practices in scientific computing." PLoS computational biology 13.6 (2017): e1005510.