Private or public

• you should notice near the top right corner a button ‘Make Public’
  • this tells you that your project is currently private
  • this means nobody can see it but you (or any collaborators you add)
• typically you would make a repository public when it has been accepted for publication, or if you publish a pre-print
  • you can also make it public before this, but this is something to discuss with your collaborators

Contributors

• repository contributors are typically co-authors or collaborators for a project
• click on the ‘Contributors’ tab (top right of the screen)
  • click on ‘+ Add’, find my account, and add me as a collaborator with ‘Read’ rights
  • make sure the ‘Bibliographic Contributor’ button is checked
  • this just means that I will be included as bibliographic author if this repo is ever cited
• go back to the project page, do you see any changes?

Adding files

• our purpose for creating an OSF project was to share our data and materials
  • to do this, we navigate to the ‘Files’ tab
• rather unfortunately, we can only upload files (i.e., not entire folders)
  • this has the benefit of meaning our folder structure must be intentional
  • but the drawback that it’s quite tedious if you want to share a large project
• let’s start by adding our data and scripts
  • add a folder called data
  • and another folder called scripts or code, or whatever you prefer

Adding data

• under data, add the three csv files you presumably have in the same folder in your project (drag and drop them, or select the big green +)
  • data_lifetime_pilot.csv
  • tidy_data_lifetime_pilot.csv
  • tidy_data_lifetime_pilot_dictionary.csv

Adding scripts

• under the scripts folder add the scripts where we worked with the data:
  • our wrangling script
  • our tables script
  • our data visualisation script

Adding PDF output

• optionally, you can also upload the PDF output produced by each script
  • this means that anybody viewing your project doesn’t have to download the Quarto scripts to see what was done (as they aren’t viewable in-browser)

Structuring your scripts/ folder

• unlike the data folder, how you organise and name this folder on OSF is more flexible
  • because we (likely) aren’t accessing these scripts from somewhere else in the project (unlike loading data from the data folder)
• you can include them in sub-folders if you prefer
  • the structure of this folder is organisational, and not fundamental to reproducibility
  • more organised folders make it easier to navigate for someone not familiar with the project structure
  • keeping this structure identical to your actual project structure is also ideal for on-going larger projects, but it’s up to you

Checking reproducibility

• a code review refers to when somebody else checks your code
  • this should also include a check for reproducibility
  • as well as validity and good coding practices (not our focus right now)
• why should we do it?
  • firstly, everybody makes mistakes! increases the chances they’ll be fixed
  • tests reproducibility
• let’s do a quick code review of our own OSF repos, checking to see if we can download and re-run our own analyses

Download OSF repo

• let’s start by downloading our OSF repo
  • from the project overview page, go to the ‘Files’ pane
  • click on ‘OSF Storage (Germany - Frankfurt)’
  • Click ‘Download as zip’ button and store somewhere useful/rename as needed

Figure 2: How to download an OSF repo

Reproduce your analyses

• first, close all R projects you currently have open
  • this is because RStudio might try to open your downloaded scripts in an already open RProject, which we don’t want
• now, navigate to the zip you just downloaded and decompress it (double-click)
  • select a Quarto script from scripts/
  • try to run the script, does it run?
  • probably not…let’s discuss why

Revisiting reproducibility

• we’ve shared the code, not just the data
  • this has been strongly encouraged in the reproducibility research as of late (e.g., the title Share the code, not just the data…, Laurinavichyute et al. (2017))
  • but is this sufficient to ensure long-term reproducibility?
  • Laurinavichyute et al. (2017) (among others) suggest many more steps that should be taken to improve reproducibility
• our focus is on sharing data and analyses with the aim of reproducibility, not just documenting what was done
  • so we have to share what is necessary to make our project reproducible
  • e.g., that it can be run with the same environment on another machine?
• so what should we share?

Improving code reproducibility

• what structural dependecies do our scripts have?
  • e.g., filepaths and folder names
• consider, for example, how we accessed the data from our scripts
  • did we use setwd()?
  • did we use filepaths?
  • no, we used the here() package within an R project
  • this meant we used our project root directory as our working directory
• so, we should, at minimum, also include the .Rproj file at the project root directory

Reproducibility spectrum

• reproducibility is on a continuum, referred to as the reproducibility spectrum in Peng (2011) (Figure 3)
  • linked means “all data, metadata, and code [is] stored and linked with each other and with corresponding publications” (Peng, 2011, p. 1227)
  • executable is not explained, and is more difficult to guarantee long-term as it depends on software versions
  • but at minimum we can assume it refers to code running on someone else’s machine

Figure 3: Source: Peng (2011)

Packages

• included the .Rproj file won’t mean that the person who downloads it will also have our packages
  • e.g., they might not have the here package, and won’t even be able to use our code to load in the data
• as we discussed some weeks ago, this is what the renv package does
  • we created project library, i.e., a lockfile (renv.lock) which is a project

Auto-loaders

• we also need to include our .Rprofile file
  • this is our auto-loader
  • whenever we open the R project, this file will be run
• it currently contains just source("renv/activate.R")
  • this means: when you open the R project, run the renv/activate.R file
• so, we need to include our renv/activate.R file in our OSF repo
  • including these two will automatically install the relevant version of renv

README

• remember to update your README accordingly!
  • this can be updated as you add more to your project
• the project README.md will ideally have information that is useful once the project is downloaded in its entirety
  • e.g., brief info about the project/data
  • description of the folder/file structure
  • any info required for reproducibility
• e.g., anybody who downloads the project will need to run renv::restore() to restore your project library (but this will only work if they’re using the same R version!)
  • so be sure to include that info!

REAMDE renv explanation

For example, you could add something like this:

**Reproduce analyses**: Once you open this project, `renv` will automatically be installed. After this is complete, you please run `renv::restore()` to restore the project package library. This will not affect the package versions you have already installed globally on your machine.

OSF repo structure

Figure 6: Your OSF should now look like this

Code review

• we’ll again try to reproduce our own analyses before sharing the OSF project with a peer
• again, close all R projects you currently have open
• now, navigate to the zip you just downloaded
  • select a Quarto script from scripts/
  • try to run the script, does it run?

Sharing your project

• we need to share our project with others
  • your project is still private
  • so you need to produce a link because the URL won’t work for non-contributors
• produce a View-only link
  • you can do this in Settings (top right)
  • give an informative name (so you remember why you created this link)
• if you select Anonymize, your name will be removed from the project
  • this is useful for e.g., blind peer review
  • but will not remove your name from your scripts!

Swapping project URLs

• go to Moodle and add your OSF repo URL
• go to someone else’s OSF repo and download their project
  • inspect the project metafiles (e.g., README)
  • try to reproduce the analyses, can you?