How do I organize research data files?

The rule that saves the most trouble is the separation of raw and processed. Raw data is written once and never modified. Every transformation happens in a script that reads from raw and writes to processed, so the processed files can always be regenerated and the raw files are always the ground truth.

That single discipline solves several problems at once. It makes the analysis reproducible, since the path from raw to result is recorded in scripts rather than in a sequence of manual edits nobody remembers. It removes the fear of breaking something, because processed files are disposable. And it means an error found in month eighteen can be fixed by correcting a script and rerunning it.

The folder structure that supports it is simple and worth deciding before collection begins: raw, processed, scripts, outputs, docs. Add subfolders inside those as needed. What matters is that the top level tells anyone opening the project what kind of thing lives where.

A published example of the same idea splits the project into Admin, Evaluation, Original data, and Reports and manuscripts, with Code and Derived data sitting inside Evaluation and Result data inside Original data (Hassenstein and Jung, 2025, p. 5). The same authors are explicit that this is not a universal standard. They expect you to adapt it to institutional, project, or personal requirements, and they accept that reorganizing old directories is often impractical, so their actual recommendation is to pick one scheme and apply it consistently to new projects (Hassenstein and Jung, 2025, p. 4). Decide the structure at the same time you write the project outline, along with what gets collected, where it lives, who may access it, and what happens to it after the thesis is finished (Michener, 2015, p. 1).

The documentation folder is the one people leave empty. It should hold a readme explaining the structure, a codebook defining variables, and a log of anything unusual, such as a participant whose data was excluded and why. That log is the thing you will most want and least remember to write.

A readme has a known minimum content. Put a README in each dataset or major project folder covering what data is included, the original purpose or project it belongs to, who created it, the date or period of creation, and the software or technical particularities needed to open it (Hassenstein and Jung, 2025, p. 6). Add the variable definitions, units, missing-value codes, and transformations next to it, and record which script produced each derived file.

What is a good file naming convention?

Date first in ISO form, then project or dataset, then content, then version, joined by underscores or hyphens with no spaces. So 20260806_interviews_transcript_p07_v02.docx. That sorts chronologically by default, it is readable by both people and scripts, and it survives moving between operating systems.

Avoid spaces, punctuation, and non-ASCII characters. They break scripts, they break on some systems, and they turn into unreadable escapes in file paths.

Keep names short enough to read and long enough to be unambiguous. If you cannot tell two files apart from their names, the convention is not carrying enough information, and if the name runs to eighty characters it is carrying too much.

One published pattern puts the elements in a different order and adds the contributor: project or document context, main contributor, version, then date, as in TenR_Man_01_MJH_v01_2025-01-01.docx (Hassenstein and Jung, 2025, p. 5). Either order works as long as you use one of them everywhere, including on your laptop, the institutional network drive, and any shared cloud folder. The same paper notes that this kind of standardization is routinely skipped and that the cost shows up later as failed retrieval and friction in collaboration, and it points at batch-renaming tools for bringing existing files into line (Hassenstein and Jung, 2025, p. 4).

How do I version files without chaos?

Use version control for code and text, and a strict numbered convention for everything else. Never use final, or final2, or finalrevised. If two people edit the same file, add initials as well as a number, and keep one file that records which version is current.

Version control is worth the learning cost for anything you write repeatedly, including a thesis. It gives you a full history, it lets you recover a paragraph you deleted three weeks ago, and it is the strongest evidence available that your writing developed over time.

For binary files that version control handles badly, such as large datasets or images, the numbered convention plus a change log is the practical answer. One line per version, saying what changed and when, kept in the documentation folder.

Version control is also the standing recommendation for reproducibility, not just for convenience. Track how every result was produced and keep all custom scripts under a version control system such as Subversion, Git, or Mercurial (Sandve et al., 2013, p. 2). If you cannot use one, the stated minimum is to archive dated copies of your scripts often enough that the main stages of development stay recoverable (Sandve et al., 2013, p. 2). For the data itself, keep at least three copies in at least two geographically separate locations, for example your computer, an external drive, and an institutional or commercial off-site service, and test periodically that the files can actually be read back (Michener, 2015, p. 5). Retention is a decision, not a default. It depends on sponsor and institutional rules, the value of the data, and whether the observations could be repeated, so simulation work may only need source code, initial conditions, and verification data, while irreplaceable observations may warrant indefinite preservation (Michener, 2015, pp. 8-9).