Appearance
When you navigate digital edition peer review, most failures trace back to three root causes: undocumented editorial decisions, a tangle of data and presentation that reviewers cannot evaluate separately, and a moving target where the edition changes while it is being read. Fix those before submission. Give reviewers a tagged, citable release of the TEI plus its ODD and documentation, alongside the live interface, and answer every report with an itemised change log rather than silent edits. This guide diagnoses the usual error signals and the fixes that satisfy reviewers at venues like RIDE.
Why does my submission get sent back immediately?
A desk rejection or "revise before review" almost always means the package was incomplete. Reviewers need to evaluate three layers, and a missing layer stalls everything:
text
Layer 1 Texts + apparatus -> reading text, variants, emendations
Layer 2 Data model + encoding -> TEI, ODD, encoding guidelines
Layer 3 Interface + delivery -> website, search, citation, archivingIf you only send a URL, the technical reviewer has nothing to inspect. Ship a release tarball or repository tag containing the TEI, the ODD, the documentation, and a one-page guide to what each part is.
How do I fix "editorial decisions are undocumented"?
This is the number-one complaint, and it is cheap to pre-empt. Write a short editorial declaration covering: normalisation policy, emendation policy, how uncertainty is marked, and what you chose not to encode. Then expose a few worked examples:
xml
<choice>
<sic>recieve</sic>
<corr resp="#ER">receive</corr>
</choice>
<!-- policy: silent for obvious typos pre-1700; flagged with corr otherwise -->When a reviewer can see the rule and an instance of it applied, the objection evaporates.
How do I answer the sustainability objection?
Reviewers fear an edition that dies with its website. Demonstrate independence of data from presentation:
| Reviewer worry | Evidence that closes it |
|---|---|
| Locked to one platform | TEI validates against a documented ODD |
| Vanishes if the site dies | Source deposited in Zenodo / repository |
| Cannot be reused | Open licence (CC BY) on text and code |
| Undocumented build | README plus a reproducible render step |
Cite the DOI of your deposit in your response letter. A reviewer who can re-download and re-validate your TEI rarely presses the point further.
What should the review package actually contain?
Freeze a version. Tag the repository (git tag v1.0-review), archive that tag to get a DOI, and send reviewers that snapshot. This solves the moving-target problem: their report cites a fixed state, and you cannot accidentally undermine a comment by editing the file it refers to.
A good package: live URL, tagged source, ODD, encoding guidelines, editorial declaration, sample of resolved decisions, licence, and a deposit DOI.
How do I handle harsh or contradictory reviews?
Build a change-log table mapping each comment to an action:
text
R2.4 "normalisation inconsistent in letters 30-40"
-> Fixed; reran consistency check; see commit a91f2.
R1.7 "prefer diplomatic over normalised default"
-> Declined; explained reader-study rationale in §2.Where two reviewers disagree, do not pick a winner in silence. State your reasoning for each and let the editor adjudicate. Editors respect a defended position far more than reflexive compliance.
What about timelines?
Digital edition review is slow because reviewers do real work: validating XML, testing search, checking links. Three to nine months is normal. If you are on a grant, schedule submission well before the funding ends and assume at least one revision round.
Key Takeaways
- Most rejections come from incomplete packages — ship data, model and interface together.
- Document editorial policy with worked examples; this defuses the top complaint.
- Answer sustainability worries with a validated ODD, an open licence and a deposited DOI.
- Freeze a tagged, citable release so reviews reference a fixed version.
- Reply with an itemised change log, not silent edits.
- Defend, with reasons, where you disagree; let the editor settle contradictions.
- Plan three to nine months and at least one revision into your schedule.
Frequently Asked Questions
Who actually reviews a digital scholarly edition?
Typically two or three reviewers split across competencies: a subject specialist for the texts and apparatus, and a technical or methodological reviewer for the data model, encoding and sustainability. Venues such as RIDE recruit explicitly for both sides.
What is the single most common reviewer complaint?
Undocumented editorial decisions. Reviewers cannot judge a normalisation, an emendation policy or an inconsistent tag if the encoding guidelines and a sample of decisions are not written down and supplied with the submission.
How do I respond when a reviewer says my edition is not sustainable?
Show the separation between data and presentation: that your TEI validates against a documented ODD, that the source is archived independently of the website, and that a third party could re-render it. Cite your deposit (Zenodo, an institutional repository) and your licence.
Should reviewers see the website, the TEI, or both?
Both. Give reviewers the live interface and a tagged release of the underlying TEI plus the ODD and documentation, ideally as a citable snapshot so their report refers to a fixed version that will not change mid-review.
How long does digital edition peer review take?
Expect three to nine months at a dedicated venue, longer than a journal article because reviewers must inspect data, validate encoding and test an interface. Build that into grant timelines rather than treating publication as instant.
What do I do with a contradictory pair of reviews?
Do not silently pick one. Reply to each point in a change log, state where you complied and where you disagreed with reasons, and let the editor adjudicate. A transparent rebuttal carries more weight than capitulation.