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).
|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|
|Documentation||Include 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.||✔|
|License||Select 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. choosealicense.com 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 description||Create 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 organization||Are 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.||✔|
|Authors||Create 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
|Other resources||Which other resources are relevant and useful for the intended audience?||GitHub repository, associated papers, similar software, project homepage etc.||✔|