Decide the venue before drafting. SoCC — the ACM Symposium on Cloud Computing — is the only conference co-sponsored by SIGMOD and SIGOPS, and that joint sponsorship is its identity: it sits at the systems-and-data intersection of cloud research. Reviewers read for a cloud contribution that matters at scale, and the venue explicitly welcomes not just clean-slate systems but measurement studies, experience papers, and cloud-economics work that a pure OS/networking flagship might treat as second-class. A technically strong paper whose real home is kernel scheduling, network fabric, or query-optimizer internals is respected and then routed elsewhere.
The decisive question is rarely "is this cloud?" but "does this contribution live at the systems-and-data intersection that SoCC owns, or is it a pure-systems or pure-data result better served by a specialized flagship?" SoCC's sweet spot is the paper that a datacenter operator or cloud platform team would act on: storage and data services, resource management and scheduling, serverless, multi-tenancy, big-data and ML-systems infrastructure, edge/fog, and the cost and economics of running all of it.
| Signal in your project | Better home | Why |
|---|---|---|
| Cloud infrastructure at the systems+data intersection: storage/data services, resource mgmt, serverless, ML-systems infra, multi-tenancy, cloud economics | ACM SoCC | The joint SIGMOD+SIGOPS venue; welcomes systems and measurement/experience |
| Core is a novel OS/kernel or a clean-slate distributed-systems mechanism, depth over cloud framing | OSDI / SOSP | OS and systems flagships; deeper systems-novelty bar |
| Core is the network — datacenter fabric, congestion control, RDMA, SDN | NSDI | Networked-systems flagship |
| General systems contribution, European rotation, OS/runtime flavor | EuroSys | Broad systems venue; ACM, different community and calendar |
| Solid systems/experience result that fits a broad practitioner venue | USENIX ATC | General systems + experience; USENIX template and process |
| Core is a database engine, query processing, transactions, or data mgmt theory | SIGMOD / VLDB | Data-management flagships; SoCC shares SIGMOD sponsorship but is systems-facing |
| Pure ML modeling result whose cloud consequence is incidental | an ML venue | The model, not the cloud system, is the contribution |
Two quick tests sharpen a borderline verdict:
Fit is necessary but not sufficient: the same idea sits at different doors depending on how far the evidence has come. A mechanism evaluated only in simulation needs a testbed or deployment before the research track; a measurement study needs a trace or corpus a reviewer can scrutinize; an experience paper needs a system that was actually operated. Submitting a simulation-only systems claim invites the "does this hold on a real deployment?" reject that both sponsoring communities apply.
[Scope] scan the last two SoCC programs (dblp conf/cloud, acmsocc.org) for your subarea
-> 3+ recent papers = a reviewer pool exists; 0 = opening or mismatch
[Citations] is your bibliography a mix of systems (OSDI/NSDI/EuroSys/ATC/SoCC) and data
(SIGMOD/VLDB) venues? -> a SoCC paper usually cites both lanes
[Calendar] SoCC has two rounds/year; compare the nearer round with OSDI/NSDI/EuroSys/ATC and
SIGMOD/VLDB dates -> route to the nearest honest fit, but never reuse a Round-1 reject
in Round 2
[Audience] who acts differently if the claim holds? -> cloud operators / platform teams / data-infra builders?
[Claim type] cloud system / measurement / benchmark / experience / cloud-economics
[Intersection check] does it span systems AND data/scale, or is it pure-OS / pure-network / pure-DB?
[Sibling check] kernel depth -> OSDI/SOSP; network fabric -> NSDI; DB engine -> SIGMOD/VLDB
[Verdict] SoCC research track / sibling venue, with a one-line reason
Run this before the writing skills; a wrong venue decision wastes every later step. When the
verdict is SoCC, continue with socc-workflow for the two-round calendar and socc-writing-style
for the paper shape.