7 Data & code sharing | The TADA-Wiki

7.1 What archiving is for

The SORTEE guidelines set out three goals (Pick et al. 2026). They pull in slightly different directions, and each needs different practices.

1 Data reuse Prevents data loss, enables research synthesis and meta-analysis, allows re-analysis as methods improve, and allows new questions to be asked of existing data, which in turn reduces the number of animals used in experiments.

2 Transparency Readers can see what was done to obtain the reported results. Open data will not stop fabrication, but it makes fabrication much easier to detect.

3 Computational reproducibility Someone else can reproduce the published results from the archived data and code.

Two further points from the guidelines (Pick et al. 2026):

Data are typically collected with public money, so they can be seen as a public good that should not be lost when a researcher changes job or a computer breaks. Lost data and code are a substantial source of research waste.
Published results are often not described in enough detail to be included in a meta-analysis. Archiving the data lets a synthesist re-analyse them to get what they need, which substantially increases the evidence available for synthesis.

7.2 Vocabulary

Key terms from the SORTEE glossary (Table 1; Pick et al. 2026). People use these terms loosely, but the distinctions matter when someone asks you for “the raw data”. The Glossary defines these and other terms used in this wiki.

Term	Meaning
Metadata	A description of, and information about, the data and code. Typically a text file called a README; variants include a codebook or a data dictionary.
Raw data	Unprocessed and unfiltered data, including any raw files such as photos, audio recordings, videos and data sheets.
Data filtering	Removing some data to create the dataset used in the analysis, for example removing individuals with a certain characteristic. The result is filtered data.
Data processing	Transforming data from one form to another: extraction from images or video, summarising, transforming, calculating. The result is processed data.
Repository	A framework providing long-term storage for many projects, such as Zenodo, Dryad or Figshare.
Project	A collection of files archived for a specific manuscript. This is similar to what GitHub calls a repository, which is the source of some confusion.
Data editor	An editorial position at a journal, responsible for screening and quality-controlling the data and code archived alongside manuscripts under review.
Data and code quality control	Checking the suitability of data and code for public archiving.

Transcribing data from a written to a digital format, and the error-checking that follows, does not count as processing. A typed-up field sheet is still raw data.

7.3 What data to share

Ideally, share both raw and processed data. The SORTEE guidelines accept three forms, with (b) and (c) as fallbacks where a full raw upload is not possible (Guideline 1.3; Pick et al. 2026):

a) Raw data, along with the processed data and/or the code to prepare the data for analysis.

b) A sample of raw data alongside the processed and filtered data, when a full raw data upload is not possible.

c) Processed and filtered data with a detailed description of how to both obtain and process or filter the raw data.

Raw data matter because filtering and processing are prone to mistakes, and without the raw data nobody can check those steps. Option (c) is acceptable, but it depends entirely on your written description being complete.

7.4 File formats

The rule is the same for data as for code: files should be universally interoperable, meaning they can be exchanged and used across different software and operating systems.

Data formats

Prefer simple text-based formats. .csv, .tsv and .txt are the most interoperable formats.

All verdicts below are from the SORTEE guidelines (Pick et al. 2026).

Format	Verdict
`.csv`, `.tsv`, `.txt`	Preferred. Maximally interoperable.
`.parquet`	Interoperable, highly compressed, efficiently read, and highly accurate for large datasets.
`.xlsx`	Not proprietary, so interoperable, but can carry information such as formatting that is lost on import into statistical software.
`.xls`	Proprietary format. Avoid.
`.RData`, `.rds`	Usable with open-source software, but requires knowledge of R to extract, and may depend on the R version used to save it. Restricts reuse.
`.sps` and other proprietary formats	Not interoperable; do not facilitate reuse.
`.pdf`, `.docx`	Never. Prone to error when copy-pasted, and cannot be readily imported into statistical programs.

SPSS .sps files appear here as unsuitable, yet Transferable gives them as an example of a file type that passes. Both are right, because they judge different things. This table is about data files, where .sps is a proprietary format. The Transferable test is about code files, where an .sps syntax file can at least be opened in a text editor.

Where there is no alternative, as with data collected by proprietary software, provide the non-interoperable file alongside interoperable extracted data, and describe the conversion in the metadata, including the software version used.

Code formats

Code must be in a format that text editors and IDEs such as VS Code can open: .R, .py, .cpp and so on. Code must not be provided as a .pdf or pasted into a Word document, because copying code out of these formats can introduce errors. Transferable explains why.

7.5 Metadata: what a README must contain

The Documented chapter covers the code README in detail. The SORTEE guidelines say what is needed on the data side (Pick et al. 2026), and the two overlap heavily.

General information

Manuscript title and abstract
Authors and relevant contact information
Date and location of data collection
A list of all relevant funders
Licence information, for example CC-BY
Information about data derived from other sources, such as other articles or online data

Detailed file descriptions

What each data file contains and how it is structured
What variables it contains
What units of measurement they are in
How they link to the data described in the manuscript, so that every column in a .csv is explained

You can put this in the main README, in separate README files for data and code, or in a data dictionary for each data file, for example a .csv with one column for variable names and another for their descriptions.

The guidelines’ standard for both data and code metadata is “adequate”: detailed enough that anyone can understand the data, or the analysis code, without reading the manuscript (Pick et al. 2026). A README that only makes sense next to your methods section does not meet it.

Under double-blind review, some sections must be left blank until acceptance and filled in then.

On LLMs. The SORTEE guidelines add that the README should say whether and how the authors have used large language models in code generation (Resnik & Hosseini 2025), though a data editor is unlikely to be able to verify this (Pick et al. 2026).

7.6 Licences

Without a licence, data cannot be legally reused in many circumstances, depending on jurisdiction, and most researchers know little about licences. The same goes for code. Data and code usually need different licences: Creative Commons licences such as CC0 or CC BY for data, and software licences such as MIT or the GPL for code. The SORTEE guidelines require a licence for both, but state a preference only for code, where they suggest permissive licences (Pick et al. 2026).

How to choose and attach a licence, for both data and code, is covered in The licence in the Documented chapter.

7.7 Checklist

A sad cartoon dog wearing a wizard hat A happy cartoon dog wearing a wizard hat

Try doing all of these to make the dog happy.