micro-author-response

MICRO Author Response

MICRO 2026 scheduled a combined rebuttal/revision window, June 3–17 — two full

weeks, which is generous by conference standards and changes the strategy: there is

time to run new experiments, not merely to argue. Whether the cycle permitted an

updated PDF versus text-only responses is 待核实 on the live pages; the playbook

below works under either mechanic.

Hour zero: classify before drafting

Read all reviews twice, then sort every distinct objection into exactly one bucket:

| Bucket | Example | Winning move |

|---|---|---|

| Factual misread | "No overhead analysis" — but Table 5 exists | Point precisely: "Table 5, rows 3–6" |

| Methodology doubt | "Baseline prefetcher looks untuned" | Run the check they imply; report numbers |

| Missing experiment | "How does this behave at 16 cores?" | Two weeks is enough — run it |

| Scope disagreement | "Should also handle GPUs" | Bound the claim; do not promise a new paper |

| Taste / significance | "Gains feel incremental" | Reframe headroom-captured %, cite the oracle bound |

Decision-relevant buckets are the middle three. A rebuttal that spends its length

on the misreads and the taste disputes has conceded the methodology fight.

The MICRO-specific physics of rebuttals

• Methodology objections dominate outcomes here. This community's reviewers

audit configs (see micro-review-process). The strongest rebuttal sentence at

MICRO is a number from a run completed inside the window: "With the reviewer's

suggested DRAM timing, geomean speedup moves from 8.4% to 8.1% (per-workload data

in the response)."

• The two-week window is a lab sprint. Pre-stage it: keep the simulator tree

and manifests warm from April (the micro-reproducibility ledger exists for

this). Budget days 1–2 triage, days 3–10 runs, days 11–13 drafting, day 14 buffer.

• Anonymity persists. No identifying repo updates, no "in our ISCA paper" — the

guidelines keep double-blind obligations alive through this window.

• Tone is enumerated policy. MICRO's 2026 guidelines make unprofessional

language in rebuttals grounds for rejection and for reporting to ACM/IEEE. Strip

every trace of indignation; a hostile reviewer is answered with data and courtesy.

Response architecture

Global note (3-5 lines): the one misunderstanding shared by multiple reviews,
corrected once with evidence pointers. New results summarized in one table.

Per reviewer, numbered:
  R1.Q1  [misread]     Table 5 rows 3-6 report exactly this; summary: ...
  R1.Q2  [new run]     Ran 16-core config (same manifest, cores=16):
                       geomean 6.9%, no regression beyond -1.2% (mcf). 
  R2.Q1  [scope]       Agreed this targets CPUs; title/claims already scoped; GPU
                       extension noted as future work, no claim made.
Close each: what text will change in the final version (one line, concrete).

Rules of the form: answer the question asked, lead with the number, never promise

what you did not run ("we will evaluate X" convinces nobody at a venue that can

check), and never introduce a result you cannot back with a manifest.

Sentence surgery: weak versus strong response lines

| Weak (deflects) | Strong (answers) |

|---|---|

| "We believe our baseline is reasonable." | "The baseline matches [12]'s config (Table 2); its SPEC-int MPKI of 4.1 sits inside the published 3.8–4.4 envelope." |

| "We will add this experiment to the final version." | "We ran it: at 16 cores, geomean 6.9% (was 6.2% at 8), full table below." |

| "The reviewer misunderstands our mechanism." | "To clarify §4.2: marking does not evict; eviction waits for a demand miss, so a false positive costs a re-fetch only if the line was truly reused." |

| "This is orthogonal to our contribution." | "Agreed it is out of scope; the claims in §1 are already limited to CPUs, and we will make that explicit in the abstract." |

The pattern in every strong line: a location in the paper, a number, or a bounded

concession — something the reviewer can verify without trusting you.

Prioritization under a length cap

If the cycle imposes a word/character cap (待核实), spend it in this order:

1. The objection most likely to flip a negative review — usually the sharpest

methodology doubt from the most engaged reviewer.

1. Any misread shared by 2+ reviewers (cheap, high yield).
2. New-experiment results, compressed to geomean + worst case + pointer.
3. Everything else in one-line acknowledgments.

Reviewers who see their main concern answered with a run tend to advocate in the

discussion phase; reviewers who see it deflected tend to dig in.

Coordinating a multi-author response

The two-week window fails most often on coordination, not content:

• Assign one owner per reviewer (drafts that reviewer's answers) and one

editor who merges voices into a single register — patchwork tone reads as

disarray.

• The runs and the prose proceed in parallel: owners draft placeholder sentences

with [NUMBER] holes while the queue executes; the editor rejects any

placeholder that survives to day 13.

• Freeze at day 14 minus 12 hours. Last-minute additions skip the tone audit and

the manifest check — the two audits this venue punishes skipping.

After submission of the response

Nothing more can be sent — hold to that even if a reviewer question haunts you;

unsolicited chair contact to append arguments reads badly at any venue. Log what was promised (the "text will change" lines) —

they become the camera-ready worklist if accepted (micro-camera-ready) and the

revision spec if rejected (micro-workflow fallback lattice). Archive the new

runs' manifests beside the response text; whichever way July 7 goes, that

evidence gets reused. Notification for the 2026 cycle: July 7.

Output format

[Objection ledger] misread N · methodology N · new-experiment N · scope N · taste N
[Flip target] <reviewer + objection chosen as priority 1, and why>
[Run plan] experiments launchable in window: list with day estimates
[New numbers] <headline results produced during window, manifest paths>
[Tone audit] zero sarcasm/indignation: confirmed
[Promises logged] camera-ready worklist entries: N