ACM Computing Surveys Review Time

ACM Computing Surveys publishes surveys, tutorials, and perspectives. A CSUR survey is expected to organize a field, not only summarize papers.

That changes the review process. Reviewers are not only checking whether the manuscript is correct. They are asking:

• Is the surveyed field defined correctly?
• Are foundational and recent papers covered?
• Does the taxonomy or framework actually help readers understand the field?
• Are comparison tables fair and reproducible?
• Does the manuscript overlap too much with a recent CSUR survey?
• Can broad computing readers learn the topic from the article?

A normal research article can sometimes be reviewed by two or three narrow specialists. A CSUR paper often needs people who understand different branches of the topic. That is why reviewer recruitment and major revision can take longer.

The official ACM Computing Surveys author guidelines explain submission mechanics and manuscript preparation. The current first-party route is the ACM Computing Surveys author guidelines, with submissions handled through the CSUR ScholarOne portal. ACM's associate-editor guidance also emphasizes maintaining review turnaround and checking the editor center regularly.

Those sources are useful, but they do not give authors one guaranteed first-decision number. For planning, combine official ACM workflow expectations with public author reports and CSUR's own manuscript type.

The safest read is:

• a very fast return usually means the manuscript did not clear CSUR fit;
• a first round of a few months is normal for a serious survey;
• a longer first round is not automatically good or bad;
• revision time depends on whether reviewers ask for new literature coverage or a rebuilt taxonomy.

The current SciRev listing is a useful caution, not a stable median. As of this review, the SciRev community page for ACM Computing Surveys shows 1 review and reports 28 days for immediate rejection, while first-review-round duration is listed as unavailable. That is why this page does not claim a SciRev median for full CSUR peer review. A single immediate-rejection report can support the desk-screen range, but it cannot support a full-review median.

These constraints matter for review time because they decide whether the manuscript enters reviewer recruitment cleanly. A formatting fix may cost a day. A missing taxonomy, weak inclusion rule, or unaddressed recent CSUR overlap can cost an entire revision cycle.

The worst reaction is to treat silence as acceptance probability. At CSUR, silence more often means the paper is hard to place with the right reviewers.

The common slow-review patterns are:

• Cross-subfield scope. The survey touches machine learning, systems, HCI, security, databases, or theory in a way that needs more than one reviewer community.
• Unclear taxonomy. Reviewers can see the topic is important, but the organizing framework is not yet convincing.
• Reference-boundary disputes. The manuscript claims comprehensive coverage, but reviewers disagree about what belongs in the field.
• Recent-survey overlap. A related CSUR or major survey appeared recently, so editors need to decide whether the new manuscript is distinct enough.
• Weak survey method. Search strategy, inclusion criteria, comparison dimensions, or coding rules are not reproducible.

These are not just timing issues. They are submission-readiness issues.

Survey architecture without an original taxonomy. A CSUR manuscript can be long, careful, and heavily cited but still fail the core survey test: it has to organize the field for readers. Reviewers are not only asking whether the cited papers are relevant. They are asking whether the taxonomy, framework, timeline, architecture map, or comparison method makes the field easier to understand. When the taxonomy is implicit, every reviewer has to infer a different organizing principle. That creates slow reports because one reviewer may ask for a methods-first structure, another may ask for a systems architecture, and a third may ask for an application-domain split. The fastest CSUR submissions make the taxonomy visible in the abstract, introduction, first figure, and table structure before reviewers start reading individual subsections.

Reference boundary that reviewers must rebuild. CSUR timing risk rises when the manuscript claims comprehensive coverage but does not explain search scope, inclusion rules, adjacent-topic exclusions, and the cutoff date. A reviewer who can name five obvious missing papers will often continue reading with distrust, even if the rest of the manuscript is useful. For a normal research article, a missing citation can be a minor revision. For a survey, a missing branch can imply that the whole map is incomplete. This is why reference-boundary disputes can add months: the editor may need a reviewer from the missing branch or may ask the authors to rebuild tables before a clean decision is possible.

Reviewer-panel mismatch across computing communities. CSUR often receives topics that cross machine learning, systems, HCI, security, software engineering, databases, theory, or domain applications. That breadth is attractive, but it makes reviewer assignment harder. A reviewer who knows the learning algorithms may not be able to judge deployment systems. A systems reviewer may not care about the human-factors claims. A security reviewer may reject a taxonomy that ignores threat models. When the manuscript does not name the intended reader community, editors have to assemble a panel that can cover the paper's full promise. That is a review-time problem and a positioning problem.

Recent-CSUR overlap not addressed. CSUR reviewers are sensitive to whether a new survey is needed now. If a recent CSUR, IEEE, Springer, Foundations and Trends, or major conference survey already covers the field, the submission needs a direct differentiation paragraph. "We review recent work" is usually too weak. The manuscript should say whether it contributes a new taxonomy, covers a new technical transition, adds a reproducible comparison matrix, integrates previously separate communities, or updates a field after a major methodological shift. Without that argument, the paper may survive initial triage but then slow down when reviewers compare it against the closest existing surveys.

The papers that move more cleanly usually make the reviewer's job easier:

• the abstract states the survey contribution, not only the topic;
• the first figure shows the taxonomy, timeline, architecture, or framework;
• the paper explains why this survey is needed now;
• the reference boundary is explicit;
• comparison tables are readable and defensible;
• the cover letter names recent adjacent surveys and explains the difference.

That package can still take months. But it gives editors a clearer path to the right reviewers.

The practical takeaway is that "review time" is not one number. A narrow, well-scoped tutorial and a sweeping cross-community survey may both fit CSUR, but they do not create the same editorial workload.

Only weakly.

A long review means the manuscript probably did not fail the most obvious desk screen immediately. That is useful. But it does not mean reviewers agree with the scope, taxonomy, or contribution.

For CSUR, a long first round often means one of three things:

So do not wait passively. While the paper is in review, prepare a revision map around coverage, taxonomy, and recent-survey differentiation.

This page uses current first-party ACM pages, the live CSUR ScholarOne route, ACM associate-editor guidance, SciRev's current visible community listing, and public author reports. The important limitation is that CSUR does not publish a stable official first-decision median in the public author guidelines, and the visible SciRev page has 1 review, not enough for a full-review benchmark. We therefore treat the 1 to 3 week desk/triage window and 2 to 4 month full-review range as planning ranges, not official performance claims.

For conversion and submission planning, that limitation is useful. It prevents the common mistake of optimizing for a fake exact median. The decision authors actually need is whether their survey architecture is strong enough to justify entering a review process that may take several months.

In our pre-submission review work with computing and information-systems manuscripts, CSUR timing risk usually comes from survey architecture, not from grammar or formatting.

The recurring failure pattern is a manuscript that is long and well cited but still does not tell reviewers how the field should be organized. That kind of paper may enter review because the topic is plausible, then slow down because every reviewer sees a different missing branch.

ACM Computing Surveys abstract says "comprehensive" before it says what changed. In CSUR-targeted drafts we review, the abstract often names a broad computing topic, then promises a comprehensive review without naming the organizing contribution. That weakens triage because the editor cannot tell whether the manuscript is a new survey, a tutorial, or a long background section. The fix is testable: the abstract should name the taxonomy, comparison matrix, architecture map, or methodological lens before it lists application areas. If the abstract could introduce ten other surveys with only the topic words swapped, it is not yet CSUR-specific enough.

ACM Computing Surveys taxonomy figure arrives too late. We often see the strongest framework hidden after several pages of literature summary. For CSUR, that delays reviewer confidence. The taxonomy figure or equivalent table should appear early enough that reviewers can use it as a reading map. It should separate branches, assumptions, inclusion criteria, and comparison dimensions in a way that a reviewer can challenge line by line. If the first figure is only a generic workflow diagram, reviewer comments tend to drift toward "scope unclear" or "organization needs improvement," which can turn a first decision into a major revision rather than a cleaner editorial path.

ACM Computing Surveys reference boundary is not auditable. A CSUR survey needs a defensible explanation of what was included, what was excluded, and why adjacent literatures were left outside the boundary. In manuscripts we pre-screen, the risky version is a reference list that looks deep but has no search logic, cutoff date, database scope, or exclusion rationale. Reviewers then rebuild the boundary themselves, usually by naming missing citations, missing benchmarks, or missing subfields. That is slow because the editor may need another reviewer from the disputed branch.

ACM Computing Surveys comparison tables do not answer the reviewer question. The table count can look impressive while the actual comparison dimensions remain generic. CSUR reviewers need tables that expose tradeoffs, assumptions, evaluation settings, datasets, algorithms, and reproducibility limits. If the comparison table is mostly author/year/topic, it will not shorten review. It makes reviewers do the synthesis work in their reports.

Before upload, an ACM Computing Surveys submission-readiness check can test whether the abstract, taxonomy, reference boundary, comparison tables, and recent-survey differentiation are strong enough before you commit to a months-long review path.