sigmetrics-author-response

name	sigmetrics-author-response
description	Use when responding to ACM SIGMETRICS reviews, covering any initial rebuttal and — distinctively — the one-shot revision response letter that must map every item on the reviewers' required-changes list to a concrete change in the revised POMACS paper, resubmitted to a subsequent rolling deadline and re-reviewed once by the original reviewers under double-anonymity.

SIGMETRICS Author Response

Use this after SIGMETRICS reviews are released. The defining SIGMETRICS response is the one-shot revision letter: if you receive a One-Shot Revision decision, you get exactly one chance to resubmit a revised paper (to one of the next two rolling deadlines) accompanied by a letter that closes the reviewers' explicit list of required changes. Any initial-round rebuttal is secondary; the revision letter is where the paper is won.

Triage

• Answer what affects the decision: model rigor, proof correctness, assumption validity, the soundness and fairness of empirical/simulation evidence, novelty, and reproducibility.
• Use evidence that already exists or that the revision will concretely add — a completed proof case, a new simulation, a validated assumption — never a vague promise.
• Correct factual misreadings first; a reviewer who misread a lemma or a plot is often persuadable.
• Preserve double-anonymity in any letter that circulates before decision (the Operational Systems Track excepted).

The one-shot revision response letter (the distinctive SIGMETRICS move)

A One-Shot Revision is single-shot: there is no second revision, so the letter must demonstrate that every item on the required-changes list is resolved. It is a change ledger:

[R1.1] Required change (quoted briefly): "prove the bound holds for the heavy-tailed case"
       -> Action: DONE  | added Thm. 1 case (b) and its proof in §3.2 (App. B for the full derivation)
       -> Where: §3.2, Appendix B; simulator run in artifact/sim/heavy_tail.ipynb validates it
[R2.1] Required change: "validate the M/G/1 assumption against a real workload"
       -> Action: DONE  | added §5.1 fitting the service-time distribution to the trace; QQ-plot Fig. 6
[R2.2] Required change: "compare against the size-aware optimal, not only the default"
       -> Action: DONE  | added the SRPT-style baseline, tuned with an equal budget (Table 2)
[R3.1] Required change: "discuss estimation error in fetch size"
       -> Action: DONE  | §6 quantifies degradation under estimation error and bounds it

The rule that turns a One-Shot Revision into an acceptance: close the whole list. Because the revision is re-reviewed once against that list, an item neither done nor explicitly and convincingly justified as infeasible is what the single shot punishes.

Choosing the resubmission deadline

• You may target one of the two subsequent deadlines — pick the later one if closing the list needs a real proof or a new measurement campaign; do not rush a single-shot revision into the nearer deadline and leave an item half-done.
• Keep the paper under the SIGMETRICS process while revising: submitting the same work elsewhere before withdrawing is a simultaneous-submission violation.

Reviewer pushback patterns

Pushback	What it signals	SIGMETRICS-ready response
"The proof omits a case / an assumption is unstated"	Rigor/correctness doubt	Add the case or state the assumption explicitly; give the full derivation in an appendix
"The model assumption is unrealistic"	Construct validity of the model	Fit the assumption to a real workload/trace; quantify the gap and bound its effect
"The baseline is not the right/optimal one"	Fairness of the comparison	Add the strongest baseline (e.g. size-aware optimal), tuned with an equal, documented budget
"Simulation and analysis are not shown to agree"	Validation gap	Overlay the analytic curve on simulated measurements with confidence intervals
"Not reproducible"	Open-science gap	Ship the seeded simulator, trace-processing scripts, and analysis notebooks

Anonymity in the letter (easy to slip)

• Refer to your own prior work in the third person, as in the paper.
• Describe artifact changes without linking to an identity-revealing repository; use the anonymized location.
• Do not thank a named collaborator or funder inside a letter that circulates before decision.

Calibration

• Respond to the criterion the reviewer actually raised, not the one you would rather defend.
• The revision, not the letter, carries the argument — the letter maps the list; the paper proves the point.
• Length/format norms for the letter vary by cycle; confirm the current instructions before sending.

Output format

[Turn] initial rebuttal / one-shot revision response letter
[Resubmission deadline] which subsequent rolling deadline, and why
[Priority issue] <reviewer required change>
[Decision dimension] rigor / proof / assumption validity / evidence / novelty / reproducibility
[Change ledger] <required change -> DONE/JUSTIFIED-INFEASIBLE + where in paper/appendix/artifact>
[List-closure check] every required change resolved? yes/no
[Anonymity check] <no identity leak in the letter: passed/issues>