overview

agenda

A full week (5 working days ) is required to perform the trainning in good conditions. This time is best used in a single continuous event and we don’t recommand splitting the training over several weeks.

The trainning week is alternating classes in the morning and group project in the afternoon.

During morning sessions, a specific tool is introduced, followed by tailored exercice to put this tool in immediate practice.  Those morning exercices are performed by each student alone, in a non collaborative fashion.  The goal here is to make sure each student acquires the minimum skill level to make good use of the proposed tool. For each tool we propose a module where you will find the introduction to the tool and supportive exercices.

While there is some leeway on how to arrange the introduction of the different tools in the morning we recommend to start by git and gitlab (or github), which play a very central role in the way we conduct the afternoon session.  To follow requirement from the afternoon projects, we recommend to follow through with snakemake. Depending on how you want to tailor the class to your audience, docker and slurm are good for a dev centric approach. To tailor focus more on the data aspect of things, zenodo is more appropriate.

a typical dev-flavoured week of training

In the afternoon the students works in group on a data challenge. During those afternoon time, the goal is to foster a methodology to effectively work in a team. A team is ideally compose of 4 to 6 members. During the session, an instructor will discuss with the team to setup goals. Git issue are then created and assign to team members.

This approach ensure that more than one task is carried out in parallel within the team, forcing them to face the difficulties inherent to collaborative development.

We propose two distinct but complementary datasets, which follow different development tracks. If you can, setting up your course so two groups follow different tracks, allows them to exchange their dataset and software at the end of the week. This experience allows to face the difficulties of releasing a finish software product meeting stringent quality goals.