Providing Anonymous Code and Data to Reviewers

Because reviewers deserve open science too
open science
review process
github
git
Author

Aaron Gullickson

Published

May 9, 2018

Modified

May 9, 2018

Posting the underlying code and data for the statistical analysis in an academic paper is becoming a more common practice, although hardly universal in many disciplines. However, even when code and data are posted, it is usually made available upon publication of the paper, leaving out those who would benefit the most from access: the anonymous peer reviewers of the manuscript. Shouldn’t the people who will put your work to the most scrutiny be the ones who have full access to see exactly what you did?

It is possible in some cases, of course, to just zip up your data code files and dump them in with your manuscript submission to a journal as “supplementary material.” However, the availability of this option may vary by journal and reviewers who are used to just downloading the manuscript PDF may miss your supplementary material altogether.

In this post, I want to demonstrate a more elegant solution using the project framework of the Open Science Foundation combined with GitHub. I have used this procedure for my most recent manuscript submissions with great success. If you are not a git or GitHub user, you can ignore the final step I discuss here, but really you should become a git user.

Step 1: Prepare your files

How to properly organize your data and code files for the easy accessibility of others is beyond the scope of this post, but here I want to highlight two basic minimum requirements that should be met before you make files available to reviewers:

  1. Anonymize. You are submitting these files under anonymous peer review. Therefore, you should ensure that nothing in the files can identify you. Remove all names or anything else that could identify you.
  2. Provide a Guide. You need to provide some basic information that will allow readers to understand what is contained in your files. A simple README file will usually suffice. This README should explain what each of the scripts does, the order in which those scripts should be run to reproduce the analysis, and distinguish which data is from the original source and which has been constructed by the analyst. Ask yourself a simple question: Would other people be able to figure out how to replicate the analysis in these files without having me there to explain it to them? If the answer is no, then you need more documentation.