Preparing Data and Code for Publication
A growing number of journals and conferences now require, or strongly encourage, sharing the underlying data and code behind a paper’s results. Treating this as an afterthought at submission time usually means scrambling to clean up a repository nobody else was ever meant to see, and building good habits from the start of a project makes this a much smoother process when publication time arrives.
Document as you go, not at the end
Code and data that made sense to you mid-project rarely make sense to a stranger reading it cold six months later, including your future self. Comments, a clear README, and a record of what each script or file actually does are far easier to write while the context is fresh than reconstructed at submission time.
Structure the repository for someone who wasn’t on the project
A clear separation between raw data, processing scripts, and analysis code, with a documented order of operations, lets a reviewer or reader actually reproduce your pipeline rather than guessing at file dependencies.
Check what your target venue actually requires before assuming
Requirements vary widely, some venues want a public repository at submission, others only at acceptance, and some have specific approved platforms for hosting data. Confirming this before submission avoids a late scramble to meet a requirement you didn’t know existed.
Sensitive data needs a different approach, not just omission
Where privacy, ethics approval, or proprietary constraints prevent full data sharing, most venues accept a clear statement of what can’t be shared and why, sometimes alongside a synthetic or de-identified version. Silence on the issue reads worse than a well-explained limitation.
Version and archive what you publish
Using a platform that assigns a persistent identifier to your specific data and code version, rather than a repository you might later update or delete, ensures the version readers can actually reproduce matches exactly what the paper describes.
Consider licensing terms explicitly for shared code and data
An unclear or missing license leaves other researchers uncertain about how they’re permitted to use, adapt, or build on your shared materials. Explicitly stating a license, commonly an open-source license for code and a Creative Commons license for data, removes this ambiguity and encourages appropriate reuse.
Testing your own repository before publication catches most problems
Attempting to reproduce your own results from a fresh environment, using only the shared materials and documentation, before submission is one of the most effective ways to catch missing dependencies, unclear instructions, or broken file paths that would otherwise frustrate a reader trying to verify your work.
A data and code preparation checklist
- Documentation written throughout the project, not reconstructed at the end
- Repository structured clearly for someone unfamiliar with the project
- Target venue’s specific requirements confirmed before submission
- Sensitive data limitations disclosed clearly, not silently omitted
- A persistent, versioned archive used, with an explicit license attached
- Reproducibility tested in a fresh environment before publication
Frequently asked questions
What platforms are commonly used for archiving research data and code?
Zenodo, the Open Science Framework, and field-specific repositories are commonly used, many integrate directly with GitHub for code and provide persistent identifiers automatically.
Is it acceptable to share only partial data due to privacy concerns?
Yes, provided this is clearly disclosed and explained, most venues accept legitimate limitations on data sharing when transparently stated.
How detailed should code documentation be for publication purposes?
Detailed enough that someone unfamiliar with the project could run the code and understand its purpose without needing to contact you directly for clarification.