At the moment we have clear learning objectives and a nice framework for an individual lesson (i.e the introduction) but no map of how these will be used to make the overall course (especially in the time available).

It feels like the next step is to agree a time allocation for each section and the time of material that should be in each (i.e lecture or practical etc.) and then allocate these to people to create the material.

To be decided what the range is here.

For each learning objective create a course skeleton w/ the proposed lecture and tutorial structures + subheadings etc.

• where should stan code live: in the notebooks, or in separate files? If in separate files, where should those be? In the session folders or a separate directory? (decision made)
• does it make sense to enforce a notebook workflow, or would copy & paste be easier?

repo needs a readme with a broad outline of what this is about, topics covered, link to registration etc.

We should write down independent learning objectives for each part of the course.

Aim for 15 minutes. Related to #21

As the title make a first draft along the lines of #10

Currently, recovery of the underlying delay distributions is not great for the truncation model.

This could just be a feature of using a long delay with a lot of truncation but should be explored.

Things to explore.

• Prior choice
• Use of beta vs uniform censoring priors
• Length of delay
• Degree of truncation.

Final pass and review of learning objectives following: https://www.bristol.ac.uk/academic-quality/approve/approvalguidance/intendedlearningoutcomes/

          Do we want to do this to ourselves and our course participants - i.e maybe we bite the small compilation bullet and use `cmdstanr`? The advantage of this potentially is that if they can't install `cmdstan` as a dependency they can still interact with all the material as installing deps won't fail for them?

Originally posted by @seabbs in #10 (comment)

• Bottom-up forecasting.
• Forecasting gotchas
  • Aggregating forecasts from daily to weekly.

One questions here is what the simple model should be - mentioned ARIMA before but might also be interesting to have e.g. a deterministic SIR model for comparison

We probably want to use cmdstanr and thus need to read in models as files. The question is how we serve the models to course participants.

Options are:

1. as character strings (could use write_stan_file) - downside is that it clutters the code and has to be written out first,
2. as remote file, download with download.file - downside is will have to decide where to put etc.
3. as remote file, user downloads themselves - somewhat cumbersome?
4. in the nfidd package in inst (once installed), using e.g. system.file(package = "nfidd") - downside is that it won't be straightforward to edit

Of these I think (1) might still be best as people can operate from a single script file and don't have to go back and forth but there might be options that I have missed.

We should compile existing open-source resources for teaching the concepts in this course (especially ones using R), as we may be able to adapt and/or use them.

Opening this for observations / discussions on how we include stan models.

Current procedure:

stan models included in the session directories, no function includes

We load and print them in the R code included in the quarto sources

• benefits: stan model files are self-contained; CmdStanModel::print() prints the functions (with line numbers)
• drawbacks: duplication of function code, no syntax highlighting

Alternatives:

Single repository of function files

This could be e.g. in stan/

• benefits: no duplication of function code
• drawbacks: CmdStanModel::print() does not print the function code so people would have to find the files containing the function code to see what the functions do

Use the rmarkdown engine

https://mc-stan.org/cmdstanr/articles/r-markdown.html

• benefits: syntax highlighting
• drawbacks: not sure what happens with included functions, no line numbers (though could still print the model of course), doesn't correspond to the normal workflow of loading stan model, printing, sampling

As title

This is likely to prove useful in the course for communicating so should recommend setting centrally in the initial session.