Appearance
Planning an ethics review for a digital humanities project means mapping the ethical risks before you collect anything, matching them to the right level of formal review, and building a documented, repeatable process so every decision across the project stays consistent and defensible. The best practice is to treat ethics as design, not paperwork: start at the proposal stage, write it down, and revisit it. This guide gives the workflow and a working checklist you can reuse on any DH project.
Does my DH project even need a formal review?
Triage first. Not every project needs full committee approval, but guessing wrong is costly. Run this quick screen:
- Likely needs full review — living people named or identifiable, personal or special-category data, crowdsourcing with volunteers, work with or about a specific community, sensitive subjects (violence, abuse, health).
- Possibly exempt or light-touch — only published material by long-dead authors, fully aggregated public data, no human participants.
- Always ask — born-digital archives that may hide personal data, web-scraped corpora, and AI models trained on heritage text.
The safe default when in doubt is to email your ethics office at the proposal stage. An early "you're exempt" costs nothing; a late discovery that you needed approval can sink a project.
When in the project lifecycle should the review happen?
As early as possible — at the proposal, before data collection and ideally before the grant is signed. The cost curve is steep: ethical constraints designed into a pipeline are nearly free, while the same constraint retrofitted after you have ingested 50,000 records may mean re-collecting consent, rebuilding storage, or abandoning a dataset. Embed ethics checkpoints at proposal, pre-collection, pre-publication, and project close.
What does a DH-specific ethics review need to cover?
Generic human-subjects forms miss DH-specific risks. Extend your application to cover the things archives and computation introduce:
| Domain | Key question | Common DH pitfall |
|---|---|---|
| Data sensitivity | Does any source name living or recently deceased people? | Assuming "historical" means "safe" |
| Consent | Who consented, to what, and is it still valid? | Reusing data beyond its original consent |
| Community rights | Whose heritage is this, and do they govern it? | Treating Indigenous data as open by default |
| Participants | Are volunteers or crowdsourcers involved? | Ignoring volunteer welfare and recognition |
| Security | How is sensitive data stored and access-controlled? | Sensitive scans on an open shared drive |
| Outputs | What gets published, and how do takedowns work? | No plan for a post-publication complaint |
How do I write a reusable ethics checklist?
Turn the review into a versioned artefact that lives with the project, not a form filed once and forgotten. A lightweight machine-and-human-readable record keeps decisions consistent across a team.
yaml
# ethics-register.yaml
project: "Migrant Letters Corpus"
review_status: "approved"
committee_ref: "REC-2026-118"
living_individuals: "yes - redaction policy applied"
special_category_data: "religion mentioned; access-tiered"
community_consultation: "diaspora association, MOU signed"
volunteers: "yes - transcription; welfare brief + content warnings"
data_storage: "institutional repo, EU host, encrypted at rest"
retention: "10 years, then review"
takedown_contact: "[email protected]"
last_reviewed: "2026-01-08"Re-reading this file at each checkpoint is what keeps a multi-year project from drifting away from its own approved terms.
How do I handle crowdsourcing and volunteer welfare?
Crowdsourced transcription is a DH staple and a frequent ethics blind spot. Volunteers are participants: their contributions, recognition, and exposure to distressing material all engage ethics. Best practice means a clear volunteer agreement, a credit and data-use statement, content warnings on difficult collections, and a route to opt out. If volunteers will read records of violence, abuse, or trauma, plan for that exposure explicitly rather than assuming enthusiasm equals consent to harm.
Who should be in the room?
A single committee viewpoint misses harms outside its expertise. Best practice widens the review:
- Affected communities — especially where heritage or identity is at stake; consult, do not just inform.
- Data protection officer — for any personal data question.
- Collaborators and partners — shared projects need shared ethics, agreed in writing.
- Subject-matter ethics adviser — for genuinely sensitive collections.
Diversity of review is itself a quality control: each perspective catches a class of harm the others are blind to.
Key Takeaways
- Triage early; when unsure whether you need review, ask the ethics office at the proposal stage.
- Start the review before data collection — retrofitted ethics is expensive and sometimes impossible.
- Cover DH-specific risks: data sensitivity, consent reuse, community rights, volunteer welfare, security, and takedowns.
- Keep a versioned ethics register so decisions stay consistent across a multi-year project.
- Treat crowdsourcing volunteers as participants and plan for their welfare and recognition.
- Widen the review beyond the committee to communities, your DPO, partners, and advisers.
- Build checkpoints at proposal, pre-collection, pre-publication, and project close.
Frequently Asked Questions
Does a digital humanities project always need formal ethics approval?
Not always. Projects using only published, long-dead-author material may be exempt, while anything involving living people, personal data, crowdsourcing, or sensitive communities usually needs review. When unsure, ask your ethics office early rather than assume exemption.
When should I start the ethics review?
At the proposal stage, before data collection and ideally before funding is finalised. Ethics designed in is cheap; ethics retrofitted after you have built a pipeline is expensive and sometimes impossible.
What is the difference between an IRB and a research ethics committee?
They are the same function under different names: an Institutional Review Board (US) or Research Ethics Committee (UK and elsewhere) is the body that reviews and approves research involving human participants or their data.
Do crowdsourcing and volunteer projects need ethics review?
Often yes. Volunteers are participants whose data, labour, and wellbeing engage ethics, and the material they transcribe may itself be sensitive. Plan for consent, recognition, and exposure to distressing content.
What should an ethics application for a DH project cover?
Data sources and their sensitivity, living individuals and consent, community rights and sovereignty, participant or volunteer welfare, data security and retention, and a plan for outputs and takedown requests.
Who should be involved in a DH ethics review?
Beyond the formal committee, involve affected communities, your data-protection officer, collaborators, and, for sensitive collections, a subject-matter ethics adviser. Diverse review catches harms a single discipline misses.