MobiSys Review Process
Use this to reason about review-stage strategy. Reopen the current CFP, the HotCRP site, and
the organizing-committee page before making process claims — the mechanics are cycle-specific.
Process model
- MobiSys uses HotCRP for submission and review, with a paper-registration step preceding the
paper upload and double-blind review (author identities hidden since 2017).
- Review runs in two rounds. Papers that do not advance past round 1 receive an early
rejection with reviews, so authors can re-plan before the process ends. Round-2 survivors
reach reviews and a rebuttal window.
- The rebuttal is scope-limited: correct factual errors and answer specific reviewer
questions; new results are admissible only when directly responsive, or may be promised for
camera-ready (
mobisys-author-response).
- Unlike MobiCom and NSDI, the rendered 2026 CFP describes accept/reject through the rebuttal,
not a separate one-shot revision channel; treat any revision path as 待核实 per cycle.
- Accepted papers are published in the ACM Digital Library, so camera-ready compliance and
artifact badges matter as much as the initial accept.
Who reviews here
- The pool is systems-and-services researchers: people who build and measure mobile
runtimes, on-device ML, sensing services, and platforms, and who read an energy or latency
claim as something to be re-derived, not admired.
- Because MobiSys is specialized, topical matches are close; a hand-wavy device claim or an
undefined energy boundary gets caught rather than skimmed past.
- Borderline mobile-systems papers usually fall on one of three edges: an evaluation on a
single device or single run, an energy/thermal claim without a described instrument, or a
contribution that is really a better model dressed as a system.
Scoring leverage table
| Review dimension |
What raises it |
What sinks it |
| Contribution |
A system mechanism forced by the device constraint |
A model or algorithm with an incidental phone demo |
| On-device evidence |
Distributions on real hardware across devices/states |
Single-device, single-run, simulation-only numbers |
| Energy/latency rigor |
Named instrument, boundary, and sustained-load behavior |
"Efficient" with no measured joules or throttle trace |
| Clarity |
An explicit operating point (device, workload, budget) |
Latency numbers with no device or workload context |
Stage-by-stage realism
- Round 1: triage by what a systems reviewer would weigh — is the device evidence real and is
the contribution a system? A thin evaluation is the classic early reject.
- Rebuttal: windows are short and scope is narrow; a precise reply that fixes a factual error
and answers the one decision-critical question beats an exhaustive one.
- Decision: one unresolved evidence objection (single-device, undefined energy boundary)
outweighs several resolved clarity complaints.
- After accept: artifact evaluation and camera-ready are their own gates
(
mobisys-artifact-evaluation, mobisys-camera-ready).
Output format
[Current stage] submitted / round-1 / round-2 reviews / rebuttal / decision / camera-ready
[Decision actors] <reviewers / AC / chairs>
[Likely leverage] <contribution / on-device evidence / energy-latency rigor / clarity>
[Forbidden moves] <identity leak / out-of-scope new results in rebuttal>
[Next response move] <one action>
Source: brycewang-stanford/Awesome-Journal-Skills → MobiSys-Skills/skills/mobisys-review-process/SKILL.md
1---2name: mobisys-review-process3description: Use when explaining or planning around MobiSys peer review — the two-round process with an early-reject cut after round 1, the round-2 rebuttal window, double-blind HotCRP mechanics, the systems-and-services reviewer pool, and decision criteria for on-device claims, so response strategy fits how MobiSys decides.4---567# MobiSys Review Process89Use this to reason about review-stage strategy. Reopen the current CFP, the HotCRP site, and10the organizing-committee page before making process claims — the mechanics are cycle-specific.1112## Process model1314- MobiSys uses HotCRP for submission and review, with a paper-registration step preceding the15 paper upload and **double-blind** review (author identities hidden since 2017).16- Review runs in **two rounds**. Papers that do not advance past round 1 receive an **early17 rejection with reviews**, so authors can re-plan before the process ends. Round-2 survivors18 reach reviews and a **rebuttal window**.19- The rebuttal is **scope-limited**: correct factual errors and answer specific reviewer20 questions; new results are admissible only when directly responsive, or may be promised for21 camera-ready (`mobisys-author-response`).22- Unlike MobiCom and NSDI, the rendered 2026 CFP describes accept/reject through the rebuttal,23 **not** a separate one-shot revision channel; treat any revision path as 待核实 per cycle.24- Accepted papers are published in the ACM Digital Library, so camera-ready compliance and25 artifact badges matter as much as the initial accept.2627## Who reviews here2829- The pool is **systems-and-services** researchers: people who build and measure mobile30 runtimes, on-device ML, sensing services, and platforms, and who read an energy or latency31 claim as something to be re-derived, not admired.32- Because MobiSys is specialized, topical matches are close; a hand-wavy device claim or an33 undefined energy boundary gets caught rather than skimmed past.34- Borderline mobile-systems papers usually fall on one of three edges: an evaluation on a35 single device or single run, an energy/thermal claim without a described instrument, or a36 contribution that is really a better model dressed as a system.3738## Scoring leverage table3940| Review dimension | What raises it | What sinks it |41|---|---|---|42| Contribution | A system mechanism forced by the device constraint | A model or algorithm with an incidental phone demo |43| On-device evidence | Distributions on real hardware across devices/states | Single-device, single-run, simulation-only numbers |44| Energy/latency rigor | Named instrument, boundary, and sustained-load behavior | "Efficient" with no measured joules or throttle trace |45| Clarity | An explicit operating point (device, workload, budget) | Latency numbers with no device or workload context |4647## Stage-by-stage realism4849- Round 1: triage by what a systems reviewer would weigh — is the device evidence real and is50 the contribution a system? A thin evaluation is the classic early reject.51- Rebuttal: windows are short and scope is narrow; a precise reply that fixes a factual error52 and answers the one decision-critical question beats an exhaustive one.53- Decision: one unresolved evidence objection (single-device, undefined energy boundary)54 outweighs several resolved clarity complaints.55- After accept: artifact evaluation and camera-ready are their own gates56 (`mobisys-artifact-evaluation`, `mobisys-camera-ready`).5758## Output format5960```text61[Current stage] submitted / round-1 / round-2 reviews / rebuttal / decision / camera-ready62[Decision actors] <reviewers / AC / chairs>63[Likely leverage] <contribution / on-device evidence / energy-latency rigor / clarity>64[Forbidden moves] <identity leak / out-of-scope new results in rebuttal>65[Next response move] <one action>66```6768---6970**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `MobiSys-Skills/skills/mobisys-review-process/SKILL.md`
thedixitjain