Skip to content
👋 Welcome! Feel free to register (verified or anonymous) and share your thoughts or story — your voice matters here! 🗣️💬
Review Service Icon 🚀 Now Live: Our AI-powered paper review tool is available in beta! Perfect for CS conference submissions — get fast, targeted feedback to improve your chances of acceptance.
👉 Try it now at review.cspaper.org
  • Official announcement from CSPaper.org

    10 20
    10 Topics
    20 Posts
    S
  • AI-powered paper reviews for top CS conferences — fast, targeted insights to help boost your acceptance odds. Discuss anything related to the CSPaper Review Tool at review.cspaper.org: ask questions, report issues, or suggest improvements.

    22 29
    22 Topics
    29 Posts
    rootR
    Some users may experience an issue where cspaper.org and review.cspaper.org always redirects to forum.cspaper.org, making it impossible to use our tool. This problem does not affect everyone. It only happens if you visited cspaper.org during our recent domain change. ️ How to Fix You need to clear the cached redirect in Chrome. Normal cache/cookie clearing will not fix this. Please follow the steps in this video guide: : Screen Recording 2025-09-21 at 17.36.14.mp4 If this still does not resolve the problem, reply here and we’ll help further.
  • 118 Topics
    324 Posts
    rootR
    [image: 1762120962655-screenshot-2025-11-02-at-23.01.42.jpg] Source: https://x.com/tdietterich/status/1984279763964534836 The recent thread on X (formerly Twitter) – anchored by comments above from Thomas Dietterich and many researchers – signals an important shift in how pre-print servers and the computer science research community are thinking about submission, screening, publication and visibility. In this article I introduce the policy change at arXiv, reflect on its likely impact on the CS domain, and summarise / discuss the comments posted by the community. Given that our forum focuses on peer review issues in computer science, I particularly highlight the implications for publication strategies, pre-print culture, review pipelines and reputation. 1. What’s changing at arXiv? While I was unable to locate a fully-public official announcement from arXiv that precisely matches the X-thread’s description (i.e., "limiting processing to items already accepted by journals"), the thread echoes long-standing concerns about moderation, screening and the status of pre-prints. For context: arXiv’s "Policies for specific content types" page states that the standards for acceptance/modeation are: works must be of "interest to professional researchers in the field". It lists content types typically not accepted (abstracts, course projects, poster summaries, proposals for future research) and those typically accepted (articles with novel results, reviews, book chapters). Anecdotal commentary suggests that moderation decisions sometimes require a link to a DOI or journal site, which raises the sense that arXiv may emphasise "refereed / published" status in some cases. A 2023 study of computer-science preprints on arXiv found that about 66% of sampled preprints were eventually published under unchanged titles, and about 11% under changed titles. The X-thread opens with: "With respect, this policy seems strategically unsound. It responds to rising submission volume by limiting processing to items already accepted by journals…" which suggests arXiv may be moving (or is perceived to be moving) toward a stronger gatekeeping model that privileges papers already accepted by journals. In short: The discussion suggests that arXiv may be increasingly screening pre-prints by whether they have been formally accepted (or likely to be accepted) by a peer-review outlet, rather than purely presenting an un-refereed public dissemination venue. If true, that is a significant shift in messaging and practise — especially for CS, where pre-prints have often served as early dissemination. 2. Why it matters — immediate and downstream impacts for CS research Rapid dissemination vs peer-review parity Traditionally, pre-print servers (including arXiv) have offered a way for researchers to rapidly share results without waiting for the often slow peer-review + publication cycle. The 2021 guide A Practical Guide to Preprints emphasises this benefit: "share early", "build upon each other’s work", "accelerate scholarly communication". If arXiv begins to favour or require journal-acceptance (or equivalent) as part of its screening, the time-to-visibility advantage of posting may be reduced. That in turn may push researchers back toward conferences or journals as first dissemination venues, or even incentivise less open sharing. Priority, citation, reputation In many CS sub-fields, having a pre-print on arXiv (with a persistent identifier) has become part of the "priority claim" and reputation loop: Google Scholar, institutional profiles, etc count it; it signals "I’m out there". For example one comment asked: "I wonder if the actual issue is coupling ‘paper on arXiv’ with ‘citations counted by Google Scholar’ etc." If arXiv’s status becomes more selective (or "pre-print + accepted by journal" only) then the current mechanics of priority and citation counting may shift. Researchers may feel pressure to post only once accepted (losing the "early" in early dissemination) or to find alternative venues. Pre-print vs. workshop/position papers vs. reviews CS has a culture of posting position papers, survey papers, workshop articles, etc — not always destined for a full journal review. Some comments note: "Many excellent, long, and comprehensive survey papers will never make it into journals or conferences simply because of strict page or reference limits." "Why not create a CS subcategory for unreviewed position/review papers and dump those pre-prints there?" If arXiv becomes less open to "non-refereed" types (position essays, reviews, pedagogical overviews) then we may lose a space for those dissemination vectors. That risks reducing the visibility of survey/position work which nonetheless plays an important role in shaping fields. The "overflow" problem and workload One driver of any policy change is real: the rising volume of submissions to arXiv. The 2023 CS-preprint study already documents large volume expansion. Pre-print servers by design carry lower thresholds than journals, but if volume grows too fast, moderators face burdens. A policy that prioritises items already accepted by journals may simply be a pragmatic triage mechanism. But the side-effect is that it may entangle arXiv more closely with the traditional peer-review system — reducing its independence and immediacy. Implications for author behaviour, and for reviewing culture Authors may delay posting pre-prints until after acceptance or may choose alternative servers (Zenodo, SSRN, institutional repositories) to preserve the "pre-refereeing" share. Reviewers / readers may shift expectations: "If it’s on arXiv, it is already accepted (or almost)". That changes how we treat "pre-print" status. The role of community-driven review (via public pre-prints) may be weakened if the pre-print server becomes more gate-keeping. Specific to CS: Conferences, double-blind review, and pre-print norms In CS many conferences operate double-blind review; having an accessible pre-print may compromise anonymity. Some venues already have stricter rules about pre-prints (for example the policy for SIGIR 2025). Hence, if arXiv’s role changes, authors may need to rethink where they post before submission, how they link pre-prints to full submissions, and whether their dissemination strategy aligns with venue policy. 3. Discussion of user comments: Voices from the community Here is a breakdown of key comments from the thread and what they suggest: Comment by "Cranck (@sport35561) "With respect, this policy seems strategically unsound. It responds to rising submission volume by limiting processing to items already accepted by journals…" This expresses concern that arXiv may be trimming its workload by shifting filtering upstream (towards acceptance) rather than downstream moderation. The user calls this "strategically unsound" — presumably because it undermines the open-sharing ethos. Davide Venturelli (@dventu) "Why not create a CS subcategory for unreviewed position/review papers and dump those pre-prints there? I think the world needs a ‘screening-only’ venue for all sort of preprints." This suggestion resonates: maintain a separate "no formal peer-review" channel (with lighter screening) whilst preserving arXiv for more formal pre-prints. It signals users feel there is a missing niche for "pre-reviewed but not yet accepted" work. Manuel (@IamManuell) "I think being accepted as a workshop paper should be enough to be accepted on a preprint server. Maybe going forward you can change the policy with respect to this. Generally, I would have preferred a reputation-based solution…" This points to one alternative: instead of "accepted by journal" as gate, perhaps "accepted by any peer-reviewed workshop" or perhaps "author reputation" or "community endorsements" might determine pre-print acceptance. It shows frustration that survey/position papers may not fit journal mould but still deserve posting. Laurence Aitchison (@laurence_ai) "I wonder if the actual issue is coupling ‘paper on arXiv’ with ‘citations counted by Google Scholar’ etc. I wonder if arXiv could have a ‘pending’ status…" This is a sharp insight: much of the value of pre-prints comes from their being citable and indexed. If arXiv allowed a "pending" label (not counted for formal citation metrics), it might preserve early dissemination while mitigating the "priority/citation" rush. It highlights how technicalities of indexing and reputation feed policies. Michael Chen (@miclchen) "Best alternatives to posting on arXiv? SSRN? Zenodo?" Practical reaction: If researchers feel arXiv is shifting upwards in gatekeeping, they will explore alternatives. That could fragment the pre-print ecosystem in CS, with divergent repositories (Zenodo, SSRN, institutional servers) each with different norms. "Much needed. People have been posting random blog posts using paper templates." This comment voices the moderation challenge: with minimal screening, some submissions may not meet research standards (e.g., "blog posts dressed as papers"). Some portion of the moderation pressure may indeed be legitimate. "Will papers like this get a new category? cs.SP?" This underscores anxiety: authors of certain sub-fields or paper types (surveys, position) worry they may be excluded or forced into "less respectable" categories. 4. What this means for you (the CS researcher) — or how to prepare Here are some suggestions and considerations if you are working in CS, especially with respect to pre-prints, review strategy, and publication planning. Check your target venue’s pre-print policy Before posting or submitting, verify whether the conference/journal you plan supports/permits pre-prints. Some double-blind conferences may penalise you if a non-anonymised pre-print is publicly available. (See SIGIR 2025 example) Decide posting timing strategically If arXiv becomes stricter, you may choose to wait until acceptance before uploading to arXiv (if you still want the arXiv badge). Or you may choose to post earlier in a lighter server (Zenodo, SSRN) if you want immediate dissemination. If you post early, consider how you label the version (version v1 vs final version) and link to accepted version. Be mindful of versioning and citation Once a paper is on arXiv (or other pre-print server) it often gains a persistent identifier and becomes citable. If arXiv’s status shifts (e.g., "accepted only" items) then the difference between a pre-print and a formally refereed paper may blur. Maintaining clear versioning (pre-print vs accepted vs published) is good practice. For surveys/position papers or non-traditional contributions If your paper is a comprehensive survey, position piece, or a "big idea" rather than new empirical results, you may need to pre-empt the venue strategy: decide whether to target a journal, or post as a technical report/working paper, or use a dedicated repository for non-peer-reviewed work. Bear in mind the moderation environment If arXiv or other servers increase scrutiny (e.g., require that submitted work is "refereed or accepted by a traditional venue"), it may become harder to upload purely novel or speculative work. (As one commenter said: "We don’t care if the paper is written by a human or a bot. We care about if it is true or not.") Engage with the research-community culture If the community values early dissemination (to stake priority, get feedback, share code/data), then a shift in arXiv policy could push new norms (e.g., more reliance on workshops, code/data release, open comment platforms). Monitor how indexing services treat pre-prints going forward: if Google Scholar, Dimensions, etc treat "posted but not accepted" differently, then your reputation calculus may change. Prepare for fragmentation There is a possibility that CS researchers will diverge into multiple pre-print channels (arXiv for "almost accepted/refereed" papers; Zenodo/SSRN/institutional repositories for early drafts). That fragmentation could complicate discoverability, priority, and cross-field visibility. 5. Broader reflections: Peer review, open dissemination and the future The arXiv debate touches on deeper tensions in the research ecosystem: On one hand, the open dissemination model (post early, get feedback, stake priority) is core to accelerating research progress and reducing barriers. On the other hand, the quality-control model (peer review, formal publication) protects against proliferation of low-quality, unverified, or misleading work. Pre-print servers like arXiv have always been somewhere in between: non-refereed, but moderated for "interest to researchers". If arXiv shifts toward "accepted-by-journal" as a screening precondition, it effectively moves it closer to a repository of formally reviewed work — limiting its "pre-review" utility. For computer science specifically: Many innovations occur in conference-driven venues, often with rapid cycles. Pre-print servers have offered a parallel path. A change in arXiv’s gate could slow that path. At the same time, CS surveys, tutorials, position pieces, code/data releases, are part of a healthy ecosystem. Losing lightweight upload channels would thin out that variety. The link between pre-prints and metrics (citations, h-index, institutional tracking) means policy shifts will affect incentives. If only "accepted" items are counted, then posting early may not help your profile. In short: This may mark a turning point where "pre-print first" becomes less of a default for CS researchers, and "refereed+pre-print" becomes the norm (or "pre-print in non-arXiv" becomes the alternative). 6. Conclusion The debate around arXiv’s screening/policy evolution is more than a niche infrastructure change — it is symptomatic of broader shifts in scholarly communication, especially in computer science. As researchers, we must stay alert to how these infrastructural changes affect our dissemination, priority claims, review strategies, and ultimately the pace and openness of innovation. For CS communities concerned with peer review issues, this moment offers a chance to reflect on whether our pre-print norms still serve our goals (speed, openness, feedback) and what trade-offs we are willing to accept (quality control, discoverability, citation reward).
  • Discussions on the evolving landscape of academic publishing — from authorship norms and conference policies to platform shifts and ethical debates. Share insights, news, and stories shaping how research gets written, credited, and published.

    17 23
    17 Topics
    23 Posts
    rootR
    TL;DR. In 2014, a so-called “international journal” accepted a ten-page manuscript whose entire content (text, figure captions, and even a scatter plot label) repeated seven words: “Get me off your fucking mailing list.” The authors declined to pay the $150 APC, so it never appeared online, yet the episode has aged into a compact case study in predatory publishing, reviewer automation, and the brittle parts of our peer-review culture. I re-read the paper, looked at the provenance, skimmed how folks on Hacker News processed it, and ran it through a modern desk-reject workflow (cspaper.org). Verdict: even the most bare-bones LLM-assisted triage would have outperformed the “review” that led to its acceptance — by a mile. [image: 1762295113107-screenshot-2025-11-04-at-23.22.41-resized.png] 1) The stunt, in one paragraph Back in 2005, David Mazières and Eddie Kohler composed a “paper” to reply to spammy conference solicitations: ten pages where the title, abstract, sections, and references are permutations of the exact same sentence. There’s even a flowchart on page 3 and a plot on page 10 whose only labels are, again, those seven words—weaponized minimalism at its funniest. In 2014, after receiving predatory solicitations, Australian computer scientist Peter Vamplew forwarded the PDF to the International Journal of Advanced Computer Technology (IJACT). The journal returned with glowing reviews and an acceptance, pending a $150 fee — the authors didn’t pay, so it wasn’t published. The paper remains a perfect negative-control sample for any review process. 2) What this reveals about predatory publishing (and why CS got caught in the blast radius) Asymmetric effort: Predatory venues invert the cost structure. Authors invest negligible effort (copy/paste seven words); the venue still “accepts,” betting on APC revenue. Reviewer theater: The “excellent” rating shows how some venues simulate peer review (checklists, auto-responses) without any reading. Brand camouflage: Grandiose titles (“International… Advanced… Technology”) plus generic scopes attract out-of-domain submissions and inflate perceived legitimacy. Spam-to-submission funnel: Mass email blasts are their growth engine; the stunt targeted that vector precisely—and exposed it. Archival pollution risk: Had the fee been paid, the paper would have entered the grey literature of indexes most readers mistake for the scientific record. 3) How a modern desk-reject should defeat a seven-word paper I ran the same PDF through a desk-rejection rubric (as used by cspaper.org). The screenshot (attached) shows: [image: 1762295095026-screenshot-2025-11-04-at-23.11.57.png] Even a lightweight LLM-assisted triage could flag: Lexical degeneracy: ≥95% repeated n-grams across the entire body. Structural vacuum: Missing standard rhetorical slots (problem, related work, method, experiments). Citation incoherence: References are RFCs that don’t support any claim. Figure semantics: Captions/axes contain no domain entities; the plot is visually present yet semantically null. If a “journal” can’t clear that bar, something is profoundly wrong with its editorial gatekeeping. 4) Why this episode won’t die (and why it still matters for CS) It’s a perfect meme with receipts. Anyone can open the PDF, skim ten seconds, and feel the absurdity. Email is the root cause. The HN discussion immediately veered into aliasing/relay defenses (“Hide My Email,” Firefox Relay, SimpleLogin, Postfix +addressing). That’s instructive: the paper is about spam as much as peer review. CS is the canary. Our field’s velocity and conference-first culture create pressure to publish-fast — terrain where predators thrive. Automation cuts both ways. Predatory venues automated acceptance; serious venues can (and should) automate rejection of nonsense while keeping humans for judgement calls. 5) Practical takeaways for authors, reviewers, and PC chairs For authors (especially students): Venue due diligence: Check editorial board credibility, indexing, APC policies, and transparency of the review process. COPE & ISSN sanity checks: A COPE logo is not membership; verify the ISSN actually exists in the ISSN portal. Watch the spam funnel: Unsolicited invites + fast acceptance + low APC = red flags. For reviewers: Refuse review for suspicious venues. Your time legitimizes their theater. Encourage institutional training: Teach how to spot predatory features in grad seminars/onboarding. For program chairs/editors: Automate triage, not judgement. Degeneracy/boilerplate detectors and structure-aware checks. Bib sanity (out-of-scope references, self-citation barns). Figure/caption semantic mismatch checks. Show your work: Publish desk-reject reasons (anonymized) to build trust and calibrate the community. 6) A 60-second “stupidity firewall” (a suggested checklist) Scope match? One sentence explains relevance to the call. Core slots present? Problem, method, evidence, limitations. Text originality? No high-degeneracy copy, no nonsense word salad. Figure semantics? Captions and axes reference real entities/units. Reference fit? Citations actually support claims, not just exist. Author intent? No spammy metadata, no mass-submission artifacts. This kind of rubric is where LLMs shine as assistants—labeling obvious failures and freeing humans to read the borderline cases carefully. 7) Why this still makes me laugh (and wince) The paper is satire that doubles as a unit test for editorial integrity. Any venue that “passes” it has failed the most basic invariant of peer review: someone must read the paper. On the bright side, our tools and norms are better today. The cspaper desk-reject outcome shows that even a simple, transparent rubric—augmented by LLM checks—can protect serious tracks from time-wasters and protect authors from predatory traps.
  • Anonymously share data, results, or materials. Useful for rebuttals, blind submissions and more. Only unverified users can post (and edit or delete anytime afterwards).

    4 4
    4 Topics
    4 Posts
    H
    Impl. based on nr0034je9.zip . Table A: Model Performance on NLP Benchmarks Model SST-2 (Acc) MNLI (Acc) QNLI (Acc) CoLA (Matthews) Avg Score BERT-Base 91.2 84.6 90.1 58.2 81.0 RoBERTa-Base 92.3 87.4 91.8 63.1 83.7 GPT-3 (175B) 94.1 88.9 93.0 66.4 85.6 Our Method 94.8 89.7 93.5 68.9 86.7 Table B: Ablation Study on Model Components (Evaluated on MNLI) Configuration Attention Mechanism Pretraining Corpus MNLI (Acc) Full Model Multi-head Self-Attn Custom + Public 89.7 – w/o Custom Corpus Multi-head Self-Attn Public Only 87.1 – w/o Attention Refinement Block Basic Self-Attn Custom + Public 86.5 – w/o Positional Embeddings Multi-head Self-Attn Custom + Public 85.2 – Random Initialization — — 72.4
Popular Tags