socc-review-process

SoCC Review Process

Model the pipeline before interpreting any single review. SoCC — the ACM Symposium on Cloud

Computing — evaluates papers through a dual-anonymous, two-round process with a rebuttal,

and its reviewer pool is drawn from both SIGMOD and SIGOPS. The most consequential mental shift

for authors arriving from a pure systems or pure data venue is that your paper is judged on both

axes at once: a systems reviewer probes the mechanism and the deployment, a data/measurement

reviewer probes the workloads, traces, and statistical honesty — and a champion needs answers for

both.

Process model

• Submission and review run on HotCRP with dual anonymity: reviewers do not see authors and

authors do not see reviewers.

• SoCC runs two rounds per year, each a self-contained accept/reject cycle with its own

abstract, submission, author-response window, and notification. A paper **rejected in Round 1

cannot be resubmitted to Round 2** the same year.

• Each paper is read by multiple PC members spanning the systems-and-data pool, who weigh the

significance of the cloud contribution, soundness of the design, quality of the measurement

(throughput, latency, tail, and cost), realism of the deployment or trace, and

reproducibility.

• Decisions are accept / reject per round (SoCC does not run a journal-style Major-Revision

cycle); the rebuttal is the author's one written turn to move a borderline paper before the

PC discussion.

• Accepted papers appear in the ACM DL SoCC proceedings and are presented at the symposium.

Reading a decision against the axes

| Signal in the reviews | What it means | Author move |

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

| Strong on novelty, weak on evaluation realism | A systems reviewer wants a testbed/deployment, not simulation | Rebut with real-system numbers or scope the claim |

| Strong on system, weak on measurement rigor | A data/measurement reviewer doubts the workloads or stats | Defend trace/workload choice; add tail and variance |

| "Cost/tail not reported" | The cloud outcome that decides adoption is missing | Point to where it lives or concede it as a gap |

| "Overlaps prior cloud/systems work" | Novelty/delta doubt | Sharpen the delta against the nearest SoCC/OSDI/NSDI work |

| Split systems vs. data reviewer | The two halves disagree | Give the champion of each half a direct, evidenced answer |

The strategic reading: a SoCC paper wins when it satisfies both sponsoring communities, so

design the evaluation to answer a systems reviewer and a measurement reviewer, not one at the

other's expense.

How SoCC differs from its siblings

• vs. OSDI/SOSP: those flagships set a higher clean-slate systems-novelty bar and use the

USENIX/ACM systems process; SoCC's identity is the cloud + data framing and its explicit

welcome of measurement and experience papers. Never assume a shared template or calendar.

• vs. NSDI: NSDI centers the network; SoCC centers the cloud service and its data running on

the infrastructure. A datacenter-fabric paper is NSDI-shaped; a storage-service or scheduler

paper is SoCC-shaped.

• vs. EuroSys / ATC: both are broad systems venues; SoCC narrows to cloud and adds the SIGMOD

half of the reviewer pool. A paper with a genuine data-management dimension is read more

natively at SoCC than at a pure-systems venue.

• vs. a single-deadline venue: SoCC's two rounds give a second chance within the year — but

only to a different (or the same, next-year) paper, since a Round-1 reject cannot re-enter Round

2.

Who reads you

Expect a mix of systems and data-management reviewers. They check whether the deployment or trace is

real, whether tail latency and cost are reported (not just the mean), whether baselines are tuned,

and whether the measurement pipeline is reproducible. Because SoCC spans storage, scheduling,

serverless, big-data/ML infra, and cloud economics, a paper is usually matched to reviewers from its

own subarea on both sides — a thin evaluation or a hand-waved workload gets caught, not skimmed.

Where author leverage actually exists

[Before submission]  subject tags spanning systems AND data -> the right dual pool (largest lever)
[Rebuttal]           factual corrections, a missing tail/cost number, a tuned-baseline result,
                     clarifying a misread workload -- the one written turn that moves borderlines
[Round choice]       submit to the round you can make strong; a Round-1 reject forfeits Round 2
[After reject]       no in-year resubmission; reroute to a sibling flagship or wait for next year

A rebuttal moves borderline papers when it corrects a factual misreading or supplies a number a

reviewer said was missing (a p99 figure, a cost breakdown, a tuned baseline); it does not move

papers when it argues taste. The PC discussion decides; the rebuttal is evidence for an advocate.

Misreadings to avoid

• Optimizing for one community — a systems-perfect paper with a weak workload story loses the

data reviewer, and vice versa.

• Treating the rebuttal as a debate — it is bounded evidence for the PC discussion, not a

closing argument.

• Reporting only averages — tail and cost are first-class at a cloud venue.
• Assuming Round 1 is a free trial — a reject there costs the SoCC year.
• Projecting last year's cadence — round count, dates, and rebuttal format are set per edition.

Output format

[Process stage] pre-submission / awaiting reviews / rebuttal / decided
[Round] round 1 / round 2, with the no-cross-round-resubmission rule noted
[Axis map] each review point -> systems (mechanism/deployment) | data (workload/measurement) | cost/tail | reproducibility
[Leverage plan] the rebuttal move that can actually change the outcome
[Forbidden moves] identity leak / unsupported new claims / Round-1 reject reused in Round 2