EDBT Writing Style
Use this when revising the main paper. EDBT papers are read by database-systems reviewers and
published open access on OpenProceedings, so they need a data-management contribution stated on
the first page and an evaluation a skeptic trusts. The failure this skill prevents is a technically
fine paper that reads like a vague performance claim or a re-skinned ML result with a database title.
Revision rules
- Lead with the data-management contribution: the concrete problem (a storage, query-processing,
indexing, transaction, integration, or data-quality problem), why current systems fall short, the
contribution (mechanism and/or study), the evidence on real workloads, and what it enables.
- Make the mechanism reproducible in prose. Describe the algorithm, data structures, parameters,
and system integration precisely enough that a competent reader could reimplement it — vagueness
here is the "I cannot tell how it works" revise.
- Pair every claim with proportional evidence — a real workload, a tuned baseline, a measurement
at realistic scale with reported variance — not adjectives like "significantly faster."
- State scope honestly, in the body. Name where the technique helps, where it is neutral, and its
overhead or failure cases; quantify them rather than hiding them. A database reviewer's first two
objections are usually "unfair baseline" and "unrealistic scale" — pre-empt both.
- Respect the per-shape page budget as a design constraint (Regular / Experiments-&-Analysis
≤12 pages; Vision ≤6; references unlimited — reverify per cycle). References do not count, but
figures, tables, and appendices in the body do.
- Use the OpenProceedings/host template, not
acmart or IEEEtran carried from a US venue.
Paper-shape skeletons
Regular / applied-systems paper
| Section |
Job it must do |
Common failure |
| Intro |
Problem, inadequacy, contribution, evidence preview, what it enables — first page |
Leads with "data is growing," not a concrete problem |
| Background / Motivation |
Why current systems fall short, grounded |
Motivation by assertion |
| Approach / System |
The mechanism + integration, reproducibly |
Described too thinly to reimplement |
| Evaluation |
Each claim answered on real workloads vs. tuned baselines |
Unnamed dataset, untuned baseline, toy scale |
| Scope / Discussion |
Where it helps, is neutral, or costs; quantified |
Limits hidden or hand-waved |
| Related work |
Delta-first positioning against DB venues |
Citation catalog with no contrast |
Experiments & Analysis paper — the study is the contribution: foreground the methodology
(subjects, metrics, fairness, coverage, repeatability) and treat the findings as the deliverable, not
a new system.
Vision paper — a tight argument for a new direction: the problem, why now, the sketch of an
approach, and the research agenda, within the short budget; no need for a full evaluation, but the
argument must be disciplined.
Sentence-level rewrites
| Draft pattern |
EDBT-safe rewrite |
| "Our system is significantly faster." |
"reduces median query latency by X% (variance over N runs) vs. on " |
| "We evaluate on a large dataset." |
"We evaluate on <named workload/logs>, sizes ..., cluster of ... workers; config in the artifact" |
| "Results show our approach works well." |
"Under skew, straggler time drops by ...; on uniform keys, overhead is ...% (Table 2)" |
| "State-of-the-art performance." |
Claim scoped to the workloads, metrics, and scale actually tested |
| "Our method scales." |
"throughput holds from 8 to 128 workers (Fig. 2); beyond that is untested" |
Scope discipline
[Where it helps] name the regime (e.g. concentrated, detectable skew) and show it
[Where it is neutral] show the no-op case (e.g. uniform keys) so the reviewer trusts you
[What it costs] quantify overhead / memory / setup, not "negligible"
[Where it fails] state the boundary (e.g. very short queries) and measure it
-> put each of these next to the affected result, not in a deferred paragraph
Vignette: compressing an over-scoped systems paper
A draft with a sprawling background, five contributions, and nine plots: keep the two contributions
the evaluation actually supports, the plots that carry the headline result and the overhead case,
and a tight scope subsection; move parameter sweeps and secondary configurations to the artifact with
explicit forward references. The test of a good cut: a reviewer should be able to answer "what does
it do, on what workloads, versus what baseline, and what does it cost?" from the body alone.
Output format
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[Shape] Regular / Experiments-&-Analysis / Vision — budget respected?
[First-page fix] <new framing leading with the data-management contribution>
[Claim audit] <claim -> workload/baseline/scale -> where answered -> proportional? yes/no>
[Scope fix] <where-it-helps / neutral / cost / failure, placed by the result>
[Template] host/OpenProceedings template in use? yes/no
Source: brycewang-stanford/Awesome-Journal-Skills → EDBT-Skills/skills/edbt-writing-style/SKILL.md
1---2name: edbt-writing-style3description: Use when revising an EDBT paper for a data-management contribution on the first page, a reproducibly described mechanism, an evaluation that survives a database-systems reviewer, honest scope, and disciplined use of the per-shape page budget (Regular / Experiments-&-Analysis / Vision) in the OpenProceedings template.4---567# EDBT Writing Style89Use this when revising the main paper. EDBT papers are read by database-systems reviewers and10published open access on OpenProceedings, so they need a **data-management contribution stated on11the first page** and an evaluation a skeptic trusts. The failure this skill prevents is a technically12fine paper that reads like a vague performance claim or a re-skinned ML result with a database title.1314## Revision rules1516- **Lead with the data-management contribution:** the concrete problem (a storage, query-processing,17 indexing, transaction, integration, or data-quality problem), why current systems fall short, the18 contribution (mechanism and/or study), the evidence on real workloads, and what it enables.19- **Make the mechanism reproducible in prose.** Describe the algorithm, data structures, parameters,20 and system integration precisely enough that a competent reader could reimplement it — vagueness21 here is the "I cannot tell how it works" revise.22- **Pair every claim with proportional evidence** — a real workload, a tuned baseline, a measurement23 at realistic scale with reported variance — not adjectives like "significantly faster."24- **State scope honestly, in the body.** Name where the technique helps, where it is neutral, and its25 overhead or failure cases; quantify them rather than hiding them. A database reviewer's first two26 objections are usually "unfair baseline" and "unrealistic scale" — pre-empt both.27- **Respect the per-shape page budget** as a design constraint (Regular / Experiments-&-Analysis28 ≤12 pages; Vision ≤6; references unlimited — reverify per cycle). References do not count, but29 figures, tables, and appendices in the body do.30- **Use the OpenProceedings/host template,** not `acmart` or `IEEEtran` carried from a US venue.3132## Paper-shape skeletons3334**Regular / applied-systems paper**3536| Section | Job it must do | Common failure |37|---|---|---|38| Intro | Problem, inadequacy, contribution, evidence preview, what it enables — first page | Leads with "data is growing," not a concrete problem |39| Background / Motivation | Why current systems fall short, grounded | Motivation by assertion |40| Approach / System | The mechanism + integration, reproducibly | Described too thinly to reimplement |41| Evaluation | Each claim answered on real workloads vs. tuned baselines | Unnamed dataset, untuned baseline, toy scale |42| Scope / Discussion | Where it helps, is neutral, or costs; quantified | Limits hidden or hand-waved |43| Related work | Delta-first positioning against DB venues | Citation catalog with no contrast |4445**Experiments & Analysis paper** — the *study* is the contribution: foreground the methodology46(subjects, metrics, fairness, coverage, repeatability) and treat the findings as the deliverable, not47a new system.4849**Vision paper** — a tight argument for a new direction: the problem, why now, the sketch of an50approach, and the research agenda, within the short budget; no need for a full evaluation, but the51argument must be disciplined.5253## Sentence-level rewrites5455| Draft pattern | EDBT-safe rewrite |56|---|---|57| "Our system is significantly faster." | "reduces median query latency by X% (variance over N runs) vs. <tuned baseline> on <workload>" |58| "We evaluate on a large dataset." | "We evaluate on <named workload/logs>, sizes ..., cluster of ... workers; config in the artifact" |59| "Results show our approach works well." | "Under skew, straggler time drops by ...; on uniform keys, overhead is ...% (Table 2)" |60| "State-of-the-art performance." | Claim scoped to the workloads, metrics, and scale actually tested |61| "Our method scales." | "throughput holds from 8 to 128 workers (Fig. 2); beyond that is untested" |6263## Scope discipline6465```text66[Where it helps] name the regime (e.g. concentrated, detectable skew) and show it67[Where it is neutral] show the no-op case (e.g. uniform keys) so the reviewer trusts you68[What it costs] quantify overhead / memory / setup, not "negligible"69[Where it fails] state the boundary (e.g. very short queries) and measure it70-> put each of these next to the affected result, not in a deferred paragraph71```7273## Vignette: compressing an over-scoped systems paper7475A draft with a sprawling background, five contributions, and nine plots: keep the two contributions76the evaluation actually supports, the plots that carry the headline result and the overhead case,77and a tight scope subsection; move parameter sweeps and secondary configurations to the artifact with78explicit forward references. The test of a good cut: a reviewer should be able to answer "what does79it do, on what workloads, versus what baseline, and what does it cost?" from the body alone.8081## Output format8283```text84[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped85[Shape] Regular / Experiments-&-Analysis / Vision — budget respected?86[First-page fix] <new framing leading with the data-management contribution>87[Claim audit] <claim -> workload/baseline/scale -> where answered -> proportional? yes/no>88[Scope fix] <where-it-helps / neutral / cost / failure, placed by the result>89[Template] host/OpenProceedings template in use? yes/no90```9192---9394**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `EDBT-Skills/skills/edbt-writing-style/SKILL.md`
thedixitjain