Expand getting started vignette

[athowes]

The epidist vignette is quite compact and possibly difficult to read for users not familiar with the package and methods already. I suggest expanding the writing to make it easier for new users to follow. The scope of this work would be to add further descriptions, links and references, figures, tables to the getting started vignette.

[seabbs]

Yes I agree though the minor push back is that getting started vignettes do typically need to be short so some of the suggested content my work better in secondary or tertiary vignettes.

[athowes]

Suggest focusing this "Get started" vignette on clearly explaining use of the one (or perhaps two) primary modelling functions we select (see #15).

Suggests a natural additional vignette with comparison to approaches we don't think are very good (currently implemented in function code, but once deprecated can be implemented in raw brms as demonstration of how to do this).

[seabbs]

agree sounds like a good idea.

[athowes]

Rewriting this first "Get started" vignette with just the latent_truncation_censoring_adjusted_delay() model feels like a good way for me to zero in on what the important parts of the package are, and what value we are offering to users. I think it would also fit in with #16 (which feels a little abstract still, but I think one concrete part is to focus on writing vignettes and documentation).

Based on these considerations, this is what I'm going to start working on now.

[athowes]

In my view the "Getting started" vignette should be minimal and focus on:

• What is the problem that this package is solving (interval censoring and right truncation)
• How can I use the package as soon as possible with my data
  • What format do I need to put my data in so that is is compatible with the model function
  • How do I run the model function
  • How to do I extract / plot / otherwise work with the results of the model function
• For this reason, arguably "simulating data to use" should be deemphasised (this is not core functionality of the package
  • But having the data be simulated is helpful so that we can show that it works
  • Question here on how much to try to convince people that it works, versus leaving that to other vignettes
    • Something like showing how bad other approaches are is definitely something to put in other vignettes

[kgostic]

I like the idea of moving data simulation into its own vignette. Also want to point out that it's considered a best practice to include a separate data generation script in the /data subdirectory for reproducibility: https://r-pkgs.org/data.html

[athowes]

Posterior predictive check in the getting started vignette or another one? Look at simulate double censored PMF function in epinowcast.

[athowes]

Also want to point out that it's considered a best practice to include a separate data generation script in the /data subdirectory for reproducibility: https://r-pkgs.org/data.html

I did think about having test data generated and stored within the package, and then pulling that into the first vignette. However, I think as we want to have the simulation conditions available for comparison it doesn't make sense to do that, and we should just have it be simulated in the vignette (just low light it).

That said, I still think it could be good to have test data generated and available for use with package tests.

[seabbs]

The reason. to simulate the censoring process in the vignette is to try and give people some visibility about what the observation process that is happening is with the hope they can maybe understand it. Now we have more papers trying to do this it seems like less of a priority but IMO is still a good idea as long as it doesn't take up too much space vs the rest of the getting started.

[athowes]

Yes agree it's a good idea to have the simulation in. A user hopefully should read the vignette and know better "what is censoring" and "what is truncation" than when they started. I think we can go a good way towards achieving that.