MobiSys Author Response
Use this after MobiSys round-2 reviews are released. Reopen the current rebuttal instructions
and length limit before drafting, because scope and mechanics are cycle-specific. The MobiSys
rebuttal is narrow by design: it is not a revision and not a place to reargue the paper.
Scope discipline
- The rebuttal is for correcting factual errors in the reviews and answering specific
questions reviewers posed. Stay inside that scope.
- New experiments are admissible only if they directly address reviewer feedback;
alternatively, you may promise results expected by the camera-ready deadline — but only
ones you can actually deliver.
- Keep the reply double-blind: no institution, authorship, private repository, or
identity-revealing device/account detail.
- Use existing submitted evidence first: figures, appendix tables, device provenance, and the
artifact — point to them precisely rather than restating them.
Triage
- Answer concerns that affect the decision: is the system real, is the on-device evidence
sufficient, is the energy/latency claim defensible, is the contribution a system.
- Correct factual misreadings first (a reviewer who thinks you tested one device when you
tested four), then address requests for a missing baseline, an energy boundary, or a
break-condition experiment.
- One decision-critical point per reviewer beats an exhaustive reply; the AC reads for whether
the central objection was actually resolved.
Drafting pattern
- State the decision-critical correction or concession first.
- Point to exact submitted evidence (figure, table, appendix, artifact).
- Explain the systems consequence — what it means for the device claim.
- Promise a camera-ready fix only if it adds no unsupported claim and you can deliver it.
Systems-reviewer pushback patterns
| Pushback |
What it signals |
MobiSys-ready fix |
| "Evaluated on one device" |
Generalization doubt |
Point to the multi-device table, or promise the added device honestly |
| "Energy numbers are unconvincing" |
Undefined instrument/boundary |
Name the power monitor, sampling rate, and envelope already in App. A |
| "Only a 30-second benchmark" |
Throttling hidden |
Reference the sustained-load run and thermal trace, or promise one |
| "This is a better model, not a system" |
Fit doubt |
Re-anchor the contribution as the runtime/scheduling mechanism, with the ablation that isolates it |
Response micro-example
Reviewer objection: the latency win might vanish once the device throttles. Reply skeleton:
- Concede the concern is the right one to raise for sustained load.
- Point to the 20-minute run in Fig. 1 and the thermal trace in App. A, already submitted.
- Note the win holds to steady state on all four devices, with the numbers regenerable from
the artifact.
- Offer one camera-ready sentence making the steady-state result explicit in the body.
Output format
[Priority issue] <reviewer concern>
[Decision dimension] contribution / on-device evidence / energy-latency rigor / clarity
[Draft response] <MobiSys-ready anonymous text within scope>
[Evidence anchor] <figure/table/appendix/artifact item>
[Out-of-scope content removed] <reargument, identity leaks, undeliverable promises>
1---2name: mobisys-author-response3description: Use when drafting a MobiSys rebuttal after round-2 reviews — working within the scope limit (correct factual errors, answer specific reviewer questions), adding only directly-responsive new results, promising camera-ready work honestly, staying double-blind, and giving the area chair a clean rationale for a mobile-systems accept decision.4---56# MobiSys Author Response78Use this after MobiSys round-2 reviews are released. Reopen the current rebuttal instructions9and length limit before drafting, because scope and mechanics are cycle-specific. The MobiSys10rebuttal is **narrow by design**: it is not a revision and not a place to reargue the paper.1112## Scope discipline1314- The rebuttal is for **correcting factual errors** in the reviews and **answering specific15 questions** reviewers posed. Stay inside that scope.16- New experiments are admissible **only if they directly address reviewer feedback**;17 alternatively, you may **promise** results expected by the camera-ready deadline — but only18 ones you can actually deliver.19- Keep the reply **double-blind**: no institution, authorship, private repository, or20 identity-revealing device/account detail.21- Use existing submitted evidence first: figures, appendix tables, device provenance, and the22 artifact — point to them precisely rather than restating them.2324## Triage2526- Answer concerns that affect the **decision**: is the system real, is the on-device evidence27 sufficient, is the energy/latency claim defensible, is the contribution a system.28- Correct factual misreadings first (a reviewer who thinks you tested one device when you29 tested four), then address requests for a missing baseline, an energy boundary, or a30 break-condition experiment.31- One decision-critical point per reviewer beats an exhaustive reply; the AC reads for whether32 the central objection was actually resolved.3334## Drafting pattern35361. State the decision-critical correction or concession first.372. Point to exact submitted evidence (figure, table, appendix, artifact).383. Explain the systems consequence — what it means for the device claim.394. Promise a camera-ready fix only if it adds no unsupported claim and you can deliver it.4041## Systems-reviewer pushback patterns4243| Pushback | What it signals | MobiSys-ready fix |44|---|---|---|45| "Evaluated on one device" | Generalization doubt | Point to the multi-device table, or promise the added device honestly |46| "Energy numbers are unconvincing" | Undefined instrument/boundary | Name the power monitor, sampling rate, and envelope already in App. A |47| "Only a 30-second benchmark" | Throttling hidden | Reference the sustained-load run and thermal trace, or promise one |48| "This is a better model, not a system" | Fit doubt | Re-anchor the contribution as the runtime/scheduling mechanism, with the ablation that isolates it |4950## Response micro-example5152Reviewer objection: the latency win might vanish once the device throttles. Reply skeleton:53541. Concede the concern is the right one to raise for sustained load.552. Point to the 20-minute run in Fig. 1 and the thermal trace in App. A, already submitted.563. Note the win holds to steady state on all four devices, with the numbers regenerable from57 the artifact.584. Offer one camera-ready sentence making the steady-state result explicit in the body.5960## Output format6162```text63[Priority issue] <reviewer concern>64[Decision dimension] contribution / on-device evidence / energy-latency rigor / clarity65[Draft response] <MobiSys-ready anonymous text within scope>66[Evidence anchor] <figure/table/appendix/artifact item>67[Out-of-scope content removed] <reargument, identity leaks, undeliverable promises>68```
brycewang-stanford