One workflow, ordered along the research data lifecycle. Start with a data management plan and follow the steps — each links to the tool and the detailed how-to you need.
Edit me

Every research project — a PhD, a postdoc study, a lab experiment — follows the same path through the research data lifecycle. This page is that path as one workflow, not a stack of separate rules. Start at Plan and move along; each step tells you what to do and links to the detailed how-to and the tool you need.

Three pillars travel through every step

  • Data — your files, stored and backed up (Nextcloud, HPC)
  • Documentation — what the data mean and how they were made (ELN + metadata + README)
  • Analysis — the code that turns data into results (Git + JupyterHub/HPC)

Keep the three linked — the same IDs everywhere, outputs made by code, a README that maps them — and your results stay reproducible. That linkage, resting on good scientific practice, is the whole point.

The workflow

The project workflow along the research data lifecycle Six phases in order — Plan, Collect, Process and Analyse, Preserve, Publish, Reuse — with two gates (G1 when sharing, G2 when publishing) and a loop back to Plan. G1 G2 PlanDMP CollectELN · raw Process &AnalyseGit · HPC PreserveNextcloud PublishDOI · licence Reusenext project the cycle repeats — your output is the next project's input

The steps

Ordered along the lifecycle. Start at the top; each step links to the detail and the tool.

1 · Plan — before you collect anything

Write your Data Management Plan first — 20 minutes that shapes the whole project. Then create the standard folder structure and agree a naming convention. → DMP Template

project/
├── README.md          <- the map to everything
├── data/raw/          <- originals, READ-ONLY, never edited
├── data/primary/      <- raw converted to open formats (by code)
├── data/processed/    <- derived data (by code)
├── data/metadata/     <- metadata tables + data dictionary
├── src/  notebooks/   <- the code that makes everything downstream
├── results/  docs/    <- figures, tables, protocols, DMP

Naming: YYYYMMDD_project_sample_condition_type_v01.ext — no spaces, dates first, one consistent pattern.

2 · Collect — capture and document

Put raw data in data/raw/ and make it read-only (chmod -R a-w data/raw/). Record every run in your electronic lab notebook within 48 h, using the same ID you’ll use everywhere. → LabFolder

3 · Describe — metadata

Apply the metadata template at capture time; use your field’s controlled vocabulary, not free text. Never leave a blank to mean “not done”. → Metadata Templates

4 · Process & analyse — by code only

Convert raw → primary → processed with scripts (no manual edits); version code in Git; run on JupyterHub/HPC. The rule: if you deleted everything downstream of data/raw/, your code in src/ should regenerate it. → JupyterHub · Make your project FAIR

5 · Preserve — store and back up

Keep shared data in a Nextcloud group folder; back up raw 3-2-1 (3 copies, 2 media, 1 off-site); archive for the long term. → Nextcloud

6 · Share — Gate G1: leaving your private space

Before data goes to anyone else: run the FAIR self-check, clear the sharing checklist, and if the data is person-derived, follow the GDPR rules (pseudonymise; patient-identifying data stays at UKW). → FAIR Self-Check · Sharing & Publishing Checklist · GDPR & Sensitive Data

7 · Publish — Gate G2: the real publication

Deposit to a repository with a DOI and a licence — not a Nextcloud link. Use the two-track approach for sensitive data (open outputs open; individual-level data controlled-access). → Sharing & Publishing Checklist

8 · Reuse — the cycle restarts

Your published, FAIR dataset becomes the Plan-phase input for the next project — yours or a colleague’s. → RDM Lifecycle

The rules of thumb (carry these through every step)

  1. Raw data is sacred — never edit it; work on copies.
  2. Name things so a stranger understands — no spaces, dates as YYYYMMDD.
  3. One ID everywhere — filenames, metadata, lab notebook.
  4. Code, don’t click — every result is re-runnable from src/.
  5. Write it down as you go — ELN and README now, not later.
  6. Back up 3-2-1.
  7. FAIR when you share — metadata, licence, access level before anything leaves your hands.

More background and external guidance: External RDM Resources and The Turing Way.