EDBT Author Response

Use this after EDBT reviews are released. An EDBT cycle has two distinct speaking turns, and conflating them is a common mistake: a short author-feedback reply on the initial reviews, and — if you receive a revise — a full change letter accompanying a revised paper that the original reviewers re-read within the same cycle. The revision, not the letter, carries the argument.

Triage (both turns)

• Answer what affects the decision: significance of the data-management contribution, technical soundness, evaluation fairness (real workloads, tuned baselines, realistic scale), reproducibility, and clarity.
• Use evidence that already exists or that the revision will concretely add — never a vague promise.
• Correct factual misreadings first; a reviewer who misread a figure or a configuration is often persuadable.
• If the cycle is double-blind (待核实 per cycle), keep every word anonymous — no tool/repository names or affiliations that reveal identity.

Turn 1 — the author-feedback reply

Short and decision-focused. One decision-critical point per reviewer beats an exhaustive reply. Concede what is true, correct what is misread, and point to exactly where the answer lives in the submitted paper or artifact. Do not paste large new result tables the reviewers cannot yet verify; signal what the revision will add if a revise follows.

Turn 2 — the revise-and-resubmit change letter (the distinctive EDBT move)

A revise is a genuine in-cycle re-read. The letter is a change ledger: for every reviewer request, either make the change and show it, or decline it with a reason.

[R1.1] Reviewer request (quoted briefly)
       -> Action: DONE  | added the tuned <baseline> at 8-128 workers, §5.2, Table 3
       -> Where: §5.2, Table 3; artifact/exp/rq2/
[R1.2] Reviewer request
       -> Action: DECLINED (with reason) | the requested workload is not publicly redistributable;
          added a comparable public workload and stated the limit in §5.4
[R2.1] Reviewer request
       -> Action: PARTIAL | extended the scaling study to 128 workers; the 1024-worker run is
          beyond the cluster we can access this cycle and is noted as future work

The rule that turns a revise into an acceptance: no silent omissions. A request that is neither done nor explicitly declined is what the second read punishes. Because the same reviewers re-read the paper, the letter should let them find each change in seconds — quote the request, name the action, point to the section, table, and artifact path.

Reviewer pushback patterns (database-systems flavor)

Calibration

• Respond to the criterion the reviewer actually raised, not the one you would rather defend.
• Length and format norms for both turns vary by cycle; confirm the current CMT instructions before sending.
• Fit the revision to the in-cycle window — the revised paper is scored within the cycle, so scope the changes to what can genuinely be finished and verified in time.
• The PC discussion decides; write the letter as evidence for an advocate, and make the revised paper — not the letter — carry the argument.

Output format

[Turn] author-feedback reply / revise-and-resubmit change letter
[Priority issue] <reviewer concern>
[Decision dimension] significance / soundness / evaluation / reproducibility / clarity
[Change ledger] <request -> DONE/PARTIAL/DECLINED + where in paper/artifact>
[In-cycle feasibility] <can the revision be completed and verified before the revised-paper deadline?>