Book vs course

[mih]

The goal is to develop a course, based on the book while minimizing the amount of disconnected material, and therefore making it easier to evolve book and course together with the evolution of datalad

• the course and the book share the exact same content, but the former is performed, while the latter serves as the syllabus

• code examples in the book are actually executable. we use this feature to turn them into "cast" scripts. once in that form, we can use the cast_live tools from DataLad to demo them in a course installment

• each code example in the book needs to be equipped with a "caption" that can then serve as a narrative cue in the cast script. The caption could then also be displayed in the book itself.

• each code example in the book needs to get a tag or label that can be used to subselect examples that make up a shorter, but still internally consistent narrative -- this aids the generation of shorter course installments

• initially the slides of the course material are based on the "summary" components of each chapter, plus relevant key figures. once tailored to and validated by the teaching the course, their content is fed back into the book (possibly using a new dedicated markup). Each slide contains a link to the respective part of the book, where more details are available. The link is possibly implemented as a QR code.

• the order of topics in the course matches the order in the book. if it turns out that this order is suboptimal it needs to be adjusted in both book and course. consequently, the course starts with basics and a uniform narrative, and ends with more standalone scenario descriptions.

• the course starts with, or is following a "pitch" that outlines an attractive take-away for a respective target audience. Candidate pitches are any "use case" chapter.

• slide decks for course installments are based on reveal.js, and are more or less fully generated using the book sources are a (set of) templates. Each chapter has its own slide deck.

• analog to the book, each session/chapter (and in particular the early ones) must communicated in a self-evident fashion, why their content/objective is important, and applicable to practical problems a target audience can relate to.

Content (based on current book)

1. Setup: Git ID, installation, what is a terminal
2. Datasets (create, save, install, nesting): basic local version control, manual log keeping
3. Run: basic provenance tracking , automatic log keeping
4. Git-annex basics: disaster recovery (needs merge of currently disjoined chapters git-annex and help yourself
5. Collaboration: yes!
6. YODA: using the conceptual pieces optimally for maximum practical benefits -- this will be and is a mostly conceptual part

Each of these "basics" chapters is handled in a 90min installment.

After the initial sessions on "basics" and number of use case descriptions can follow.

For the initial run at INM7, we will have a dedicated "How to work with the local infrastructure" session that could take place any time after (3). This will the also turn into a use case chapter in the book.

Instead of a weekly or biweekly frequency, this course can also be tought as a 2-day block event, with the basics on day 1, and a re-cap + use cases on a (shorter) day 2.

[adswa]

Having thought about this a bit more, I think session 6 on YODA does not need to be an only conceptual session. My original plan was to include the YODA principles into the narrative as part of a data analysis midterm project. It is supposed to be extended by a section on DataLads Python API, and finished with a complete reproducible, YODA-compliant data analysis using the dataset mentioned here: https://github.com/datalad/datasets.datalad.org/issues/24

I think this makes YODA much more approachable, and would be easy to integrate into handbook and course (i just need to sit down and actually write the section ;-) ).