ACM Computing Surveys Submission Process

This page was built from ACM Computing Surveys author guidance, ACM author submission workflow pages, ACM pre-publication evaluation policy, ACM open-access pages, ACM Manuscript Central route evidence, and Manusights submission analysis for CSUR, Computer Science Review, Foundations and Trends titles, IEEE survey venues, ACM Transactions journals, and broad computing review manuscripts. Last reviewed: July 17, 2026.

Official source limitation: the ACM Computing Surveys author-guidelines page is indexed publicly, but the fetcher could not fully inspect all on-page text in this pass. The process facts here therefore combine accessible ACM policy pages, the publicly indexed ACM CSUR author-guidelines snippet, the live ACM Manuscript Central route, and the existing Manusights source ledger for the sibling CSUR requirements page. Use the live ACM page before final upload if ACM changes article-type or file-format instructions.

ACM's general author submission workflow says review submissions should use a single-column format. ACM's pre-publication evaluation policy says refereed submissions are reviewed for originality, correctness, novelty, importance, and clarity of exposition, and that submitted papers should normally receive at least three qualified independent reviews. ACM's author pages also state that, from January 1, 2026, ACM publications are open access, with 2026 APC rates depending on article type, membership, country category, and ACM Open institutional coverage.

CSUR's process is not mainly deciding whether the paper is long enough. It is deciding whether the manuscript contributes a reusable survey architecture for a computing field.

The editor is usually asking five questions:

• Does the manuscript have an original taxonomy, framework, comparison methodology, or analytical structure?
• Does the reference boundary look comprehensive for the field, not just convenient for the authors?
• Does the topic justify CSUR's broad computer-science readership rather than a subfield venue?
• Does the manuscript differentiate itself from recent CSUR, IEEE, Foundations and Trends, Computer Science Review, or specialty-survey coverage?
• Can reviewers evaluate the survey method, coverage, and synthesis claim without rebuilding the literature map themselves?

That process logic is why this page is distinct from the requirements guide. The guide tells you what to prepare. This page explains what the uploaded package is tested against.

Do not open Manuscript Central until the package can prove its survey contribution on the first read.

If the first figure and first table do not organize the field, the process is not ready.

CSUR uses the ACM Manuscript Central route at mc.manuscriptcentral.com/csur. Authors prepare the manuscript in ACM review-submission format, enter metadata, upload files, complete author and rights/policy information, and submit.

The upload mechanics matter, but they are not the CSUR fit decision. Before the final confirmation screen, confirm:

• the paper is in single-column review format for submission;
• authorship, affiliations, ORCID details, and corresponding-author information are stable;
• conflict of interest and competing-interest details are complete;
• the data availability statement, artifact notes, or corpus-search materials explain what can be inspected;
• plagiarism screen, originality, and overlap risks are handled before upload;
• source files, figures, tables, captions, and supplementary material are usable;
• ACM Computing Classification System terms match the survey scope;
• reference coverage and taxonomy files are internally consistent;
• the cover letter names the survey's organizing contribution and recent-survey differentiation.

That last bullet is the process hinge. The editor should not have to infer what is new about the survey.

Initial checks confirm the file set can be routed. They can include manuscript format, authorship metadata, conflict of interest declarations, source files, figure accessibility, references, rights information, plagiarism screen or originality checks, data availability statement, and whether required ACM submission fields are complete.

For CSUR, initial checks are also a credibility signal. A survey that claims comprehensive coverage but has weak references, missing comparison tables, or inconsistent terminology enters editorial triage looking immature. The submission should already show the field map.

Editorial triage is where the CSUR process separates survey from literature review.

This triage is where many submissions fail even when formatting is clean.

ACM policy for refereed publications says submitted papers should normally be reviewed by at least three qualified independent reviewers, and ACM policy describes refereeing as anonymous except in special circumstances. Treat CSUR as an anonymous peer-review workflow, not a transparent-review workflow. If the live CSUR page asks for double-anonymous or double-blind preparation, remove author-identifying cues from the review file, acknowledgments, repository links, and supplementary search artifacts before upload.

CSUR review usually needs reviewers who can test different parts of the survey: subfield expertise, coverage completeness, taxonomy validity, methodological soundness, and clarity for broad computing readers.

CSUR peer review often focuses on:

• whether the taxonomy is original, useful, and not arbitrary;
• whether the reference set is comprehensive across terminology, venues, and adjacent fields;
• whether the comparison tables are accurate enough to become a field reference;
• whether open problems follow from the literature map rather than from author preference;
• whether the survey belongs at CSUR rather than a narrower ACM Transactions, IEEE, Foundations and Trends, or Computer Science Review venue.

Major revisions are common for strong survey manuscripts because reviewers can request missing branches, new tables, better search logic, or clearer evaluation dimensions.

The final decision usually turns on whether the manuscript's architecture can become a durable field reference.

A fast rejection often means the paper did not clear CSUR fit, taxonomy, scope, or overlap checks. A major revision usually means the editor sees a possible CSUR paper but needs stronger coverage, sharper taxonomy, better comparison tables, or clearer recent-survey differentiation. A rejection after review means the paper reached substantive scrutiny but did not prove comprehensive contribution.

For complex or delayed edge cases, expect 4 to 6 months when reviewer recruitment spans multiple computing communities, when the field has conflicting terminology, or when the manuscript needs cross-area reviewers. A 2 to 4 month first-decision range is a planning baseline, not a guarantee.

Use these as planning ranges. Very early friction usually means the package did not prove CSUR fit. Silence after the first few weeks often means reviewer recruitment. A long first round is not automatically bad, but it should prompt you to prepare a revision map around reference coverage and taxonomy.

In our pre-submission review work with ACM Computing Surveys and adjacent survey venues, the most useful process signal appears before upload. Manusights submission analysis treats these as specific failure patterns: the abstract, first figure, taxonomy, reference boundary, comparison tables, cover letter, recent-survey differentiation, and open-problems section should all argue the same survey contribution. We see the process fail fastest when the manuscript has enough citations to look comprehensive but no reproducible map of why those citations define the field.

Literature review wearing survey language. The manuscript collects many papers, but it does not contribute a taxonomy, analytical framework, comparison method, or field map. The abstract claims comprehensiveness while the figures and tables behave like a bibliography.

Check whether your CSUR manuscript has a real taxonomy →

Reference boundary is not reproducible. The paper has many citations, but reviewers cannot see how the corpus was selected, which terms were searched, which venues were included, or why excluded work is out of scope. A large reference list is not the same as comprehensive coverage.

Check whether your CSUR reference boundary is defensible →

Recent-survey overlap is unresolved. The topic has already been mapped in CSUR, IEEE, Foundations and Trends, Computer Science Review, or a strong specialty journal. The new paper may still be publishable, but only if it names a distinct angle, new taxonomy, or field transition.

Check whether recent survey overlap weakens your CSUR route →

Scope is too narrow for CSUR. The survey is useful, but it serves one model family, benchmark, application domain, conference track, or implementation community. That work may fit an ACM Transactions journal, IEEE venue, Foundations and Trends title, or Computer Science Review better than CSUR.

Check whether CSUR or a narrower review venue owns your paper →

The strongest submissions make the survey method auditable before review. The abstract states the organizing contribution. The first figure maps the field. The first tables compare methods, systems, datasets, or evaluation dimensions rather than listing papers. The cover letter explains why CSUR readers need this survey now.

This guide tells you what CSUR editors look for in the process; the review tells you whether YOUR paper passes that process before upload. Paid Manusights reviews include a 60-day money-back guarantee, and we do not train models on submitted manuscripts.

Check whether your ACM Computing Surveys package is ready for the submission process →

• ACM Computing Surveys submission guide
• ACM Computing Surveys submission guide
• Computer Science Review submission guide
• Communications of the ACM submission guide
• Best computer science journals