# Week 9 workflow
---
Plan
- myExperience (10 min)
- checklists development (20 min)
- checklist report back (20 min)
- workflow groups (20 min)
- report back (20 min)
https://hackmd.io/@jenrichmond/Bke2nzVUu
---
myExperience
(10 min)

---
# Reproducibility checklist
Make a list of things that researchers should check they have done before they submit their work for publication to improve reproducibility
20 min
---
## Checklist Report back
- clear and concise program directory structure
- giving variables appropriate names (meaningful, human/computer readable, consistent)
- include code to produce the EVERYTHING
- make sure code can be run on a different machine (avoid setwd, use Rproj and here package)
- include an accurate codebook
- provide all the values in the figures (caption, appendix, OSF)
- details of complete reasoning for missing data, aesthetics, formatting, inclusion/exclusion criteria
- including information about ordering for variables that are factors (aka codebook)
- open materials shared in a lanuage consistent with teh readership of the journal
- double check accuracy of descriptives (or even better write your paper in papaja so that you can pull them directly and avoid errors)
- using consistent code style, formatting
- share complete unaltered raw data prior to exlcusins (i.e total transparency)
- extra detail in paper (or prereg doc) aobut how the data was analysed, LOTS AND LOTS OF DETAILS
- include a README file, how to run code, use numbers to show how code is ordered and insructions about how to use it
- make sure to include details about how scales work (0= strongly agree) ESP if the scales and codes are not consistent across questions
- when sharing code make sure it is ONLY what is needed to produce analysis, clean it up, make it as clear and concise as possible and **WELL DOCUMENTED**
-
---
# workflow
From the talk that you watched or paper that you read, agree on 3 workflow tips that are likely to be useful to the rest of us.
---
Group 1: Danielle Navarro workflow
1. A standard folder structure with documentation describing it
2. Agreed conventions for usage
3. Misellaneous 'nudges' to suggest good practice
---
Group 2: Sharla Gelfand talk to yourself
1. use chatty functions to chat to yourself – library(usethis)
2. use set up files - “talk to yourself”
3. use prescriptive templates, automate, put into package
---
Group 3: Julia Lowndes Better Science less time
1. Horizontal leadership
2. Open-mindedness in terms of tools that can be used, all sciences being incl. in data science
3. Making the education of R accessible e.g. @allisonhorst, integrating R into labs gradually, the force = R
💪👈🦆
---
Group 4: Erin Buchanan Papaja
1. Install and use **papaja** package to report statistics, tables etc.
2. Consider using markdown from start to finish (raw data --> finished maunscript)
3. Hide code you don't want to appear in the paper (include = false), but keep it in the rmd file for people to use
---
Group 5: Greg Wilson Good enough practices
1. Back up everything and use a version control system
2. Concisely record all the steps used to process data
3. Create the data you wish to see in the world
---
Group 6: Jenny Bryan version control
1. Use a git repository and git interface (e.g. GitHub, GitLab)
2. Use good git practices (e.g. pulling before pushing, meaningful commit messages)
3. Make sure working versions are pushed to master and all source files are in master
---
Group 7: Broman & Woo spreadsheets
1. Explanatory & consistent variable names (e.g. names that make sense at a glance, don’t use “male” and then sometimes write “M”)
2. Follow the correct style (e.g. YYYY-MM-DD, no missing cells {use NA})
3. Use a data dictionary/codebook
---