Software Archiving Checklist

Making data and code understandable, usable, and available enables increased research efficiency and impact. In addition, it enables things like reproducibility, a cornerstone of science. This checklist will help you be prepared to create a high quality software package that can easily be understood and (re)used by others (or yourself/lab members a year from now).

Checklist ItemDescriptionExamples 
Who is the target audience? This helps inform what kind of information/documentation to include.Other astrophysicists, the general geology community, security researchers, non-technical academics, the general public, etc.
Is the code understandable?Put yourself in others' shoes and ask yourself: "Can others realistically understand, compile and use the code without contacting me?"

This will help determine gaps in documentation and organization.
It could be that there is not enough documentation on how to compile, or the way the code is organized is hard to understand
Archiving in the JHU Data Archive
DocumentationInclude a readme file, or other form of documentation that supports understanding and usage. Document dependencies, limitations, how the software is used in a workflow, input and output data, assumptions, etc.
LicenseSelect a license for the software. This communicates how others can use and reuse the software. Note: simply making source code available is not sufficient for software to be considered open source!MIT, Apache, GNU, etc. will help you decide.

Include a file named LICENSE in the root folder of your software which contains the text of the selected license
Short descriptionCreate a short description for the software, no more than a few sentences. This will be needed for descriptive purposes for the JHU Data Archive (and many other 3rd party services)"This zipped folder contains figures for nutrient and sediment loading trends and mass balances for the Susquehanna River Basin (SRB) as well as the R script used to make these figures. File types include .pdf, .R, and .Rdata."
Code and data organizationAre the data and code organized in a way that makes sense? Are file names descriptive enough? When possible, it is recommended to separate code, input data, and output data into separate folders.
AuthorsCreate a list of those who made an original contribution to the software along with their roles. This is important to give credit.

If the software is a modification of another software, only the names of those who contributed to the current iteration are needed.
Developer, Lead Developer, Principal Investigator, Investigator, Architect,
Documenter, Tester, Project Manager
Publisher, Sponsor
Other resourcesWhich other resources are relevant and useful for the intended audience?GitHub repository, associated papers, similar software, project homepage etc.