• Understand the notion of reproducibility

• Understand the elements of a research compendium

• Understand conventions for coding styles

According to the National Science Foundation:

The calculation of quantitative scientific results by independent researchers using the original data and methods

Reproducibility can be further broken down

• empirical (eg, sample IDs, sampling gear, instrument settings)

• statistical (eg, which statistical tests, what model parameters)

• computational (eg, code, software, hardware)

We are witnessing an increasing number of examples where the original analysis cannot be reproduced

• 6 out of 53 cancer studies (Begley & Ellis 2012)

• 6 out of 360 water resource studies (Stagge et al 2019)

• 70% of researchers have failed to reproduce another scientist’s experiments; 50% have failed to reproduce their own (Baker 2016)

• commercial models are updated or retired without notice

• training data and weights are usually undisclosed

• outputs can shift from one run to the next when settings are held constant

• testing data are sometimes used in the training set (data leakage)

A standard and easily recognizable way for organizing the digital materials of a project to enable others to inspect, reproduce, and extend the research.

Marwick et al. (2018)

1. Project organization should follow the conventions of the scientific community

   • The community might be a lab group or a professional society
   • The convention(s) support reproducibility and transparency

1. Project organization should follow the conventions of the scientific community

2. Maintain a clear separation of data, methods and output

   • Separate data from code
   • Separate cleaning, analysis & output code

|-code
  |-01_data-ingest.R
  |-02_data-cleaning.R
  |-03_data-QAQC.R
  |-04_model-fitting.R
  |-05_create-figures.R
|-data
  |-skagit_steelhead-escapement.csv
  |-skagit_river-flow.csv

1. Project organization should follow the conventions of the scientific community

2. Maintain a clear separation of data, methods and output

3. Specify the computational environment

   • Which software/package(s) and what version(s)?
   • Ranges from simple text description to self-contained environments

• Increased efficiency, simplified file management and streamlined workflows

• Increased visibility and scientific impact

• Ability to return later and understand the process

Organize your compendium so another person knows what to expect from the plain meaning of the file and directory names

1. Licensing

   • Who can (re)use the work?
   • Are there restrictions?
   • Many depositories require Creative Commons licenses

1. Licensing

2. Version control

   • Facilitates private collaboration among colleagues on the project
   • Allows for distribution and maintenance of the compendium in the future

1. Licensing

2. Version control

3. Persistence

   • Consider the “life span” of the analysis
   • A Digital Object Identifier (DOI) is more permanent than a URL

1. Licensing

2. Version control

3. Persistence

4. Metadata

   • Publishing data with a DOI requires a description of the data themselves
   • who, what, where, when, how

One could always create a structure from scratch

Alternatively, consider some existing tools

• Jeff Hollister’s {manuscriptPackage}

• Carl Boettiger’s {template}

• Ben Marwick’s {rrtools}

• Scheuerell Lab’s compendium

setwd("/Users/Mark/Documents/projects/salmon/final_code")

setwd("/Users/Mark/Documents/projects/salmon/final_code")

setwd("/Users/Mark/Documents/projects/salmon/final_code")

Use relative paths to your work

The {here} package makes this really easy

## Absolute path
## setwd("/Users/Mark/Documents/projects/salmon/data")

## Relative path
> data_dir <- here::here("salmon", data")
> data_dir
> [1] "/Users/Julio/research/thesis/salmon/data"

1. Human readable

   • The name should convey concise info
   • Longer is better

1. Human readable

2. Machine readable

   • Easy to ID with regular expressions or globbing
   • Avoid spaces, capitalization, punctuation, special characters
   • Consider _ and - as delimiters

Consider all of these “special characters”

~ ` ! @ # $ % ^ & () + = {} [] |  : ” ; ’ < , > . ? / *

Consider all of these “special characters”

~ ` ! @ # $ % ^ & () + = {} [] |  : ” ; ’ < , > . ? / *

Of them, the pipe | was the only character available for use as a delimiter in a plain text file for a statewide energy efficiency database because all the others had been used in variable names

• resume.docx

• Mark's data.xlsx

• figure 1.pdf

• resume.docx – whose?

• Mark's data.xlsx – which project?

• figure 1.pdf – of what?

• scheuerell_resume_2025-01-03.docx

• marks_skagit_steelhead_age-composition.xlsx

• figure-01_scatterplot-length-mass.pdf

1. Human readable

2. Machine readable

3. Works with default ordering

   • Use a number at the beginning of a name
   • Use the ISO standard for dates (YYYY-MM-DD)
   • “zero-pad” numbers

2019-10-20_skagit_harvest-commerical.csv

2019-10-20_skagit_harvest-recreational.csv

2020-09-18_nooksack_harvest-commerical.csv

2020-09-18_nooksack_harvest-recreational.csv

01_data-ingest.R

02_data-cleaning.R

03_data-QAQC.R

04_model-fitting.R

05_create-figures.R

Taking the time to invest in these styles and strategies can save you a lot of time in the future, but in the end it’s up to you

We’ll learn about GitHub and how to use it for personal and collaborative projects