Rejected from Journal of Statistical Software? The 7 Best Venues to Submit Next

Source: Clarivate JCR 2025, the journals' own aims-and-scope and author-guideline pages, and JOSS review documentation (accessed June 2026). APCs are list prices and may vary.

1. The R Journal. If your contribution is an R package already on CRAN or Bioconductor and the novelty is the tool rather than a new method, this is the cleanest landing spot. The R Journal wants concise, readable articles that go beyond the package vignette to give context and reach a wider readership. Its software review is thorough but generally faster than JSS, and there is no APC.

2. Journal of Open Source Software. Reach for JOSS when the artifact is the contribution and you do not have a method-paper's worth of new statistics to say. JOSS reviews the software openly on GitHub, expects tests and documentation, and pairs it with a very short paper. It desk-rejects submissions under 300 lines of code and flags those under 1,000 as possibly out of scope, so it suits real, reusable libraries, not one-off analysis scripts. It is typically the fastest route on this list.

3. SoftwareX. A good general home for software in any language with demonstrated potential to impact scientific work across domains. SoftwareX reviews both the short article and the code and is faster than JSS, but it is gold open access, so factor the APC into the decision.

4. Journal of Computational and Graphical Statistics. If reviewers told you the package was fine but the methodological or graphical contribution was the real story, JCGS is the right pivot. It publishes computational and graphical methods for readers with a strong statistics background, where the method is the protagonist and the implementation is supporting evidence rather than the deliverable.

5. Computational Statistics. This Springer journal publishes methodological research and applications at the intersection of computing and statistics, with attention to complex data sets. It fits when your work is a genuine computational-statistics method, Bayesian computing, simulation, nonparametrics, that happens to ship with software, rather than a software paper that happens to contain a method.

6. Journal of Statistical Computation and Simulation. JSCS is the natural venue for algorithm-centered and simulation-study work, computer algorithms related to probability or statistics, inference studied through simulation, and interactive statistical systems. It is a Taylor & Francis title that takes submissions through the ScholarOne Manuscripts portal at ScholarOne submission portal, a different workflow from the JSS system, so budget time to reformat. Choose it when the contribution is the algorithm or the simulation evidence, not a packaged general toolkit.

7. PeerJ Computer Science. When the audience is broader computer science rather than the statistical-computing community specifically, PeerJ Computer Science takes research articles, literature reviews, and application notes across many CS subjects. It is gold open access; weigh the APC against the wider readership.

JSS does not run a publisher-wide article transfer system the way large commercial publishers do, so there is no one-click cascade to a sister title. Routing after a JSS rejection is a manual decision, which makes matching the venue to the rejection reason more important, not less. Think of it as a ladder by contribution type rather than by tier.

Practical ladder by rejection reason:

• Rejected for thin methodological novelty, but the software is genuinely useful? Step to a software-artifact venue. For an R package already on CRAN, The R Journal is the first choice; if that is rejected, JOSS (artifact-focused) or SoftwareX (any language) is the next venue.

The software work you already did carries over almost entirely.

• Rejected because the package was too narrow? Either broaden the package into a general toolkit and try JSS or The R Journal again, or accept the scope as-is and submit the narrower tool to JOSS, which welcomes focused but well-engineered libraries.

• Rejected because the contribution is really a new method, not a package? Reframe the manuscript around the method and move to JCGS, Computational Statistics, or JSCS.

Demote the software to a reproducibility artifact and lead with the statistical advance.

• Rejected for code quality, missing tests, or non-reproducible results? Do not cascade unchanged. Every venue on this list that reviews the artifact, The R Journal, JOSS, and SoftwareX, will run into the same wall. Fix the package and the replication script first, then choose by contribution type.

In our pre-submission review work with Journal of Statistical Software submissions, the rejections we see most often cluster into four named patterns. Each is specific to the editorial culture of a journal that reviews running software, not just prose, and each is testable against your own package and manuscript, which is what makes them worth checking before you resubmit anywhere.

Of the 40+ statistical-software manuscripts we reviewed for JSS-class venues, these four account for the large majority of avoidable rejections, and editors here routinely reject on them before novelty even enters the conversation. In practice, what actually happens at the desk is a reviewer cloning your repository and running your replication script, so we see the same code-readiness gaps surface again and again.

The re-implementation with no stated advantage. Across our Journal of Statistical Software pre-submission reviews, the single most common reviewer trigger is a package that duplicates what an established package already does, with an introduction that never argues why the new implementation is better. JSS asks authors to compare the new contribution against existing implementations directly, and reviewers judge usefulness, not just correctness.

The fix is a concrete comparison: name the existing packages, and show in your abstract and introduction what your software does faster, more generally, or more correctly. This is testable, open your manuscript and check whether a reviewer can find, in the first two pages, the sentence that says why your package should exist alongside the incumbents.

The narrow package framed as a general contribution. A second recurring pattern in the Journal of Statistical Software manuscripts we review is a package that solves one specific problem, presented as though it were a general toolkit. JSS prefers substantial packages that serve a discipline area or implement a family of approaches. When the software covers a single function with a thin wrapper, reviewers flag the mismatch between the framing and the artifact.

The fix is either to broaden the package, add the related methods, the diagnostics, the alternative estimators, or to honestly reframe the contribution and move to a venue like JOSS that accepts focused tools.

The thin test suite and incomplete documentation. We see manuscripts where the science is sound but the software is not review-ready: no unit tests covering core functionality, missing function-level help files, or a vignette that does not match what the package actually does. JSS expects formatted help files, a package installable from a standard repository such as CRAN, Bioconductor, or PyPI rather than only GitHub, and code that is readable and commented.

Reviewers verify the software works as the paper claims, so a missing test suite or a help file that disagrees with the code is a direct reject signal. Check that every exported function has documentation, that your tests exercise the core methods, and that the package installs cleanly from a clean environment.

The replication script that does not exactly reproduce the paper. The fourth pattern is a submission whose results cannot be reproduced exactly from the supplied materials. JSS requires replication materials for all results, preferably a single commented standalone script, and reviewers only recommend conditional acceptance after reproducibility problems are completely resolved. When a figure or a reported number differs when the reviewer runs the script, the manuscript is returned.

Before resubmitting, run your own replication script in a fresh session on a clean machine and confirm that every figure, table, and statistic in the paper regenerates exactly, including random-seed control.

Don't just resubmit the same package to the next venue. The fastest way to collect a second rejection is to send unrevised software to another journal that also reviews the artifact, The R Journal, JOSS, and SoftwareX all run your code. A rejection for fit or novelty is a routing problem you can fix by reframing the contribution and choosing the right venue.

A rejection for code quality, missing tests, or non-reproducible results is a software problem, and the same reviewers' concerns will reappear anywhere the artifact is reviewed. Be honest about which one you got.

Two cases call for real work before resubmitting, not a faster next submission. First, if reviewers questioned whether the package adds value over existing implementations, the manuscript needs an explicit, sourced comparison and possibly a broader feature set, not just a new cover letter. Second, if the tests, documentation, or reproducibility were challenged, the only fix is a stronger test suite, complete help files, and a replication script that regenerates the paper exactly.

Appealing is rarely worth it: a novelty or scope rejection is an editorial judgment, not a factual error, and given JSS handling times near fifteen months, a clean resubmission to a better-fit venue is almost always faster than the appeal queue.