Open science

Repeatability, reproducibility, and replicability

In between repeatability and reproducibility, there is also ‘runnability’ (same researcher, new machine).

Reproducibility with R(Studio)

• Make the management of the reproducibility of your project a top priority!
• Use R projects (.Rproj).
• Use a folder structure that meets the needs of your project (e.g., https://github.com/ISPMBern/project-template).
• Use sequential numbers and descriptive names for your files names (e.g., 02_analysis.R).
• Use a main or master script (e.g., 00_main.R) from which you can source other scripts:

# Main R script that sources all subsequent R scripts

source(here("R/01_cleaning.R")) # source() reads R code from a file
source(here("R/02_analysis.R"))
source(here("R/03_plotting.R"))

• Distinguish between raw and processed data. Never, ever change your raw data!
• Use Markdown files (README.md) to provide additional information.

Markdown syntax - Headings

# Header 1

## Header 2

### Header 3

#### Header 4

##### Header 5

###### Header 6

Markdown syntax - Links and images

You can use different types of (hyper)links.

You can embed [named hyperlinks](https://quarto.org/),
direct URL's like <https://quarto.org/>, and links to
[other places](#markdown-syntax---lists) in the document.
The syntax is similar for adding images:

![Markdown logo](figures/markdown.png)

So what is Quarto?

R Markdown has been around for roughly a decade and was fundamentally built for R. That’s why RStudio (now Posit) developed Quarto, a next-generation, R Markdown-like open-source scientific and technical publishing system built on Pandoc.

Quarto is as friendly to Python, Julia, Observable JavaScript, and Jupyter notebooks as it is to R. It’s not a language-specific library, but an external software application.

If you start creating reproducible documents, just use Quarto.

From QMD to HTML

---
title: "ggplot2 demo"
author: "Norah Jones"
date: "5/22/2021"
format: 
  html:
    fig-width: 8
    fig-height: 4
    code-fold: true
---

## Air Quality

@fig-airquality further explores the impact of temperature 
  on ozone level.

```{r}
#| label: fig-airquality
#| fig-cap: Temperature and ozone level.
#| warning: false

library(ggplot2)
ggplot(airquality, aes(Temp, Ozone)) + 
  geom_point() + 
  geom_smooth(method = "loess")
```

Code chunks are controllable

These are just some examples. There are a lot more options.

One last thing…

Sometimes, your analysis might depend on specific versions of R (rarely) or packages (more frequent). Regular updates of packages may break existing code. To solve this potential problem, you can use tools to ensure that you (or your collaborators, including you in 5 years time) can reproduce your environment and rerun your analysis:

• renv produces a lockfile with all information required to replicate the environment.
• groundhog installs the version of a package that existed at a particular point in time. It is slightly more lightweight than renv.

Finally, you can add sessionInfo() to your reports, which lists the used versions of R and packages.

Working with GitHub in practice

git is a command line tool - type commands into the command prompt.

RStudio offers a way to work with Git (or SVN) repositories.

It can do the most important things, but not everything (terminal use resolves this though).

GitHub also offers a nice desktop app (offering easier authentication).

The following slides assume a GitHub-first approach. This would be my recommended approach.

Your turn!!

Make a Git repository out of the folder you’ve been using the last 2 days.

• initialize a Git repository in the folder (usethis::use_git())
• commit your files using appropriate commit messages
• transfer your repository to GitHub (usethis::use_github())
• check that your content is on GitHub
• make a new change and make sure that you know how to get it to GitHub

If you have time, try the GitHub-first approach. Make a new repository on GitHub based on https://github.com/ISPMBern/project-template (click “use this template” and “create a new repository”), then clone it to your computer, make a change, and get it back to GitHub.

Collaborating on Git(Hub)

Collaborating on Git(Hub) - keeping up to date

Good practice to pull from the main repository occasionally (especially when it’s a very active repository).

RStudio doesn’t have a built-in way to do that though, nor does GitHub Studio - you have to use the command line…

Configure a “remote”… in the command line (e.g. the terminal tab in RStudio).

git remote add ispm https://github.com/ISPMBern/projects-in-R.git
git pull ispm main

If others are working on related things (e.g. they need the output from your parts), it might be useful to set a remote to their fork so that you can pull their changes and check that your work is still compatible.

Collaborating on Git(Hub) - conflicts

Conflicts occur when two commits (modifications) change the same line(s) to different things.

Git does not know what to do about it, so it needs your help.

Git will issue an error when you try to pull highlighting the issue.

Go to the offending file and find the conflict. It’ll look something like this:

If you have questions, please
<<<<<<< HEAD
open an issue
=======
ask your question in IRC.
>>>>>>> branch-a

Change the file such that it is correct - it might be the top (the remote), it might be the bottom (your version) or some combination of the two.

Commit the file(s) to complete the merge.

Exercise

Today

1. Take a data set (could be yours, a data set from medicaldata or tidytuesday, or something else).
2. Analyze/explore the data including at least one data visualization.
3. Push a short, reproducible HTML report to your GitHub repository.

The analysis does not need to be anything sophisticated. Just find something interesting in the data and tell a story about it. It does need to be reproducible though (i.e., derived from .qmd)!

Final assesment

For the final assessment by the end of the course, you will extend your report with additional statistical analyses. Send the link of the final HTML report (don’t forget to make your repository public!) to christian.althaus@unibe.ch and ben.spycher@unibe.ch (Subject: Assessment BSPR course) by 16 June 2023.

Optional: Instead of sending us the link to the HTML file in your GitHub Repository (e.g., https://github.com/calthaus/BSPR-exercises/blob/main/products/reports/report.html), you better send us the link to the HTML file on your GitHub Pages site (e.g., https://calthaus.github.io/BSPR-exercises/products/reports/report.html).