Skip to main content

Data Journalism Publishing Workflow

From fact-checking your numbers to corrections after publication — the complete publishing workflow for data-driven journalism.

Last reviewed: Next review due:

Why workflow matters in data journalism

A data error in a published article is more damaging than a factual error in a conventional story, because data errors are often more specific (a precise number that is wrong) and harder to correct cleanly. A rigorous publishing workflow — fact-checking, methodology documentation, version control, and a clear corrections process — is the professional standard for data journalism.

The BBC Shared Data Unit and Bureau Local both publish their analysis code and data alongside their stories. This is the direction the industry is moving.

The publishing workflow

1
Fact-check your numbers
Before publication, run every key number a second time from the raw data, using a different method if possible. Have a colleague check the most important figures independently. Cross-reference against published official statistics where they exist.
2
Write a methodology section
Explain in plain English: which dataset you used, where you downloaded it, what you calculated, and any significant assumptions or limitations. This is not a technical appendix — it is a transparency note for your reader.
3
Cite your sources
Link directly to the data source. If the data was obtained via FOI, publish the response document. If it is in a spreadsheet you cleaned, note what you changed from the original.
4
Approach for comment
Give the institution or individuals named in your data story a clear, specific right of reply before publication. State the finding and your deadline. Note their response (or non-response) in the article.
5
Version control with Git
Commit your analysis files to a Git repository before publication. The commit timestamp proves your analysis was complete before publication and unchanged afterwards.
6
Publish and monitor
After publication, monitor for responses from experts, affected institutions, or readers who spot errors. Data journalism stories often receive more expert scrutiny than conventional pieces.
7
Corrections process
If an error is found: correct the article immediately, add a transparent correction note, and document the error in your editorial log. Never silently update a number without noting the correction.

Reproducible analysis with Jupyter

# Structure of a reproducible analysis notebook:

# 1. METADATA CELL (markdown)
# Analysis: NHS waiting times by trust, 2024
# Data source: NHS England RTT statistics (March 2024 release)
# Downloaded: 2024-04-15 from england.nhs.uk/statistics
# Author: [name], [organisation]

# 2. IMPORTS
import pandas as pd
import matplotlib.pyplot as plt

# 3. DATA LOADING (always from the raw source file)
df = pd.read_csv('data/raw/rtt_march_2024.csv')

# 4. DATA CLEANING (documented step by step)
# Remove rows where waiting time is blank
df = df.dropna(subset=['wait_weeks'])

# 5. ANALYSIS (each step in its own cell)
summary = df.groupby('trust_name')['wait_weeks'].mean()

# 6. VERIFICATION
print(f"Total trusts analysed: {df['trust_name'].nunique()}")
print(f"Total patients: {len(df):,}")

# 7. EXPORT for publication
summary.to_csv('data/output/nhs_waits_summary.csv')

Git basics for data journalists

# Set up a new analysis repository
git init nhs-waits-analysis
cd nhs-waits-analysis

# Add your analysis files
git add analysis.ipynb data/raw/ methodology.md

# Commit with a clear message
git commit -m "Add NHS waiting times analysis — March 2024 data"

# Before publication: commit the final version
git commit -m "Final analysis — fact-checked, ready for publication"

# Share publicly on GitHub (optional)
git remote add origin https://github.com/yourname/nhs-waits-analysis
git push -u origin main

When workflow rigour is most critical

  • 1High-profile data stories that will be widely shared and quoted.
  • 2Stories about powerful institutions that will scrutinise your methodology.
  • 3Analysis that will be updated monthly or annually — version control is essential.
  • 4Collaborative stories where multiple journalists contribute to the analysis.
  • 5Stories based on data that has not been officially published before (FOI data, leaked data).

Red flags

  • Only one person has checked the key numbers — data errors are often invisible to their author.
  • The analysis exists only in a spreadsheet with no version history.
  • No methodology note was written before publication.
  • The institution named in the story was not given a right of reply.
  • A correction was made to a published article without a visible correction note.

Pre-publication checklist

  • Key numbers have been independently verified by a second person.
  • A methodology note is written and either published inline or linked.
  • All data sources are cited with links or FOI reference numbers.
  • The institution or individuals named have been offered a right of reply.
  • Analysis files are committed to version control.
  • The Jupyter notebook (or equivalent) runs from top to bottom without errors.
  • I have a corrections process ready if an error is found after publication.

Ethics and accuracy

The IPSO Editors’ Code requires prompt and prominent corrections for inaccuracies. Our ethics hub covers the full accuracy and corrections framework for UK journalists.

Common mistakes

  • Skipping the second-check because you are confident in your analysis — errors are most common when you are most confident.
  • Writing the methodology note after publication rather than before.
  • Correcting a data error silently without a visible correction note.
  • Not keeping a copy of the data as it was when you downloaded it — data portals update files and overwrite previous versions.
  • Publishing without a named contact for the methodology — expert readers need someone to email.

Related guides

Primary sources

Frequently asked questions

Should I publish my raw data and analysis alongside the story?
Yes, where possible. Publishing the underlying dataset and your analysis code (as a Jupyter notebook or R Markdown file) allows readers and other journalists to verify your work, and builds trust in your methodology. The BBC Shared Data Unit, Guardian, and FT all publish methodology notes and often data alongside significant data stories. If the data contains personal information or is subject to copyright restrictions, publish your methodology and calculations without the raw data.
What is Git and why should data journalists use it?
Git is version control software — it records every change you make to your analysis files, with a timestamp and a note. This means you can see exactly what the analysis looked like at any point, undo mistakes, and prove that your published analysis is unchanged from the version you fact-checked. GitHub and GitLab host public Git repositories where you can share your analysis code. For data journalism, Git prevents the 'which version of the spreadsheet is the right one?' problem.
How do I correct a data error after publication?
Act immediately. Correct the published article, add a clear corrections note at the top explaining what was wrong and what the correct figure is (never silently update). If the error was significant, consider whether a separate corrections article or update piece is needed. Notify anyone who shared or quoted the original figure if possible. Document the error and the correction in your editorial log. IPSO Editors' Code Clause 1(ii) requires accurate correction of published inaccuracies.