Jonas Schöley & Egor Kotov
The setting: After 6 months of silence, you finally got the reviews for your paper. It's an R&R with many requests for additional analyses. You open your project folder and can't reproduce your old results. It's hard to remember how everything worked. You wish you had documented and organized your work better.
- Project organization
- What is a project?
- Folder structure, templates, and naming conventions
- Research notes
- Code organization
- The analysis pipeline
- Defining inputs and outputs
- Configuration files
- Comments
- Code repositories
- The git version control system
- Github/Gitlab/Codeberg as online code repositories (+https://gitlab.gwdg.de/ and similar as institutional repos)
- Keeping private things private
- Code documentation
- Large file
- Data repositories
- Zenodo
- Integrating Zenodo into your code
- Integrating Zenodo and Github
- "I can’t share my data"
- Data documentation
- Advertisement of your shared resources
- Workflow automation
- Disadvantages of a single script. Namespace issues, package conflicts, etc.
- The
targetsR package for defining an analysis pipeline- Computational isolation of each target step
- Reproducing R-language dependencies (with renv, mention rix as an option)
- Listing dependencies in a project
- Package version management
- Containers for near complete reproducibility
- The problem of system level dependencies
- The container solution
- Using other peoples containers
- Building your own