---

name: edbt-author-response description: Use when drafting EDBT author responses across the two turns of a cycle — the short author-feedback reply on the initial reviews, and the in-cycle revise-and-resubmit change letter that maps every reviewer request to a concrete revision re-read by the original reviewers under the OpenProceedings process.

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)

Pushback	What it signals	EDBT-ready response
"The baseline is not tuned / not the strongest"	Soundness doubt about the comparison	Re-run with an equal, documented configuration; report the new numbers, or justify the choice
"This scale is unrealistic / too small"	External-validity limit	Extend to realistic workloads and cluster sizes, or scope the claim and name the limit
"I cannot tell how the mechanism works"	Reproducibility / clarity gap	Add the missing algorithm/parameter detail; make it reimplementable
"The artifact does not run / is missing"	Reproducibility gap	Fix and re-upload the package; describe the run path in the letter
"Overlaps prior work X"	Novelty/delta doubt	Sharpen the delta sentence; add the missing comparison
"The measurement methodology is unsound" (E&A)	Core-contribution doubt	For an Experiments & Analysis paper this is decision-critical — fix the methodology, not just the prose

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?>