Introduction

This document describes a few possible steps to self-check replication packages before submitting them to a journal. It is not meant to be exhaustive, and it is not meant to be prescriptive. There are many ways to construct a replication package, and many more to check that it works.

The key ingredient is what I call “computational empathy” - thinking about what an unknown person attempting to reproduce the results in your paper might face, what they might know and assume, and more importantly, what they might not know or know to assume. While the replication package might very well run on your computer, that is by no means evidence that it will run on someone else’s computer.

In what follows, we will assume that the replicator satisfies the following conditions:

• they are familiar with their own operating system

  • though that operating system may not be same as yours!

• they are somewhat familiar with how to run code in the “dominant” programming language in your field

  • though that does not mean that they and you run code the same way!

• they are not necessarily familiar with cutting edge methods of running software that you might be using

• they likely have some experience with how social scientists write code and prepare data, but may not have your years of experience

Content is .

How to read this document

The table of contents goes initially from easy to more complex. Each section should be seen as one method of running, with varying levels of “trust” in how robust it is to replicators’ environments. Some can be combined, others may not work well together.

TL;DR

Techy lingo for “too long, didn’t read”. A summary of the most important takeaways will be at the top of each section.

How to contribute