Journal of Statistical Software Submission Process

If those answers are weak, the process will not fix them. It will expose them during initial checks, section-editor routing, or software review.

Prepare the full package before opening the online submission flow.

You should have:

• PDF manuscript in JSS style
• LaTeX source and associated manuscript files ready for later production work
• source code for the software in readable ASCII files with comments
• package help files, documentation, examples, and installation instructions
• replication materials for all manuscript results, preferably as a single commented standalone replication script
• data files, download instructions, or external-data links when files are too large for upload
• expected output log, especially for R submissions where JSS recommends a code.html output from running the replication script
• license information showing GPL-2, GPL-3, or GPL-compatible licensing for publication in JSS
• metadata for title, abstract, contributors, affiliations, funding, conflicts of interest, and contact details

This is not just administration. JSS reviewers evaluate correctness and usefulness of both software and manuscript. A missing dependency, a long-running replication script, or an ambiguous license can slow the process before the statistical contribution is even judged.

JSS submissions start from the journal's official submissions page. The flow is part of the journal's online Manuscript Tracking System, built around a registered author account and a four-step submission sequence. For manuscripts that clear the first checks, plan for a first decision in 4 to 12 months, with complex software ecosystems, uncommon languages, long manuscripts, or difficult replication scripts pushing reviewed decisions beyond that range.

The step-by-step guide describes the sequence:

1. register or log in and ensure the account has the Author role
2. start the submission and acknowledge the journal conditions
3. upload the PDF manuscript and all additional material
4. assign file types for software package, reproduction script, reproduction material, data, or related reference material
5. enter title, abstract, contributors, and other metadata
6. confirm the submission and finish

The upload step is where many JSS submissions become slow. The system accepts the PDF and additional files, but the editor still has to decide whether the package is reviewable. In our JSS process reviews, the upload fields expose whether the manuscript is controlled: file names, package version, replication script, output log, license, dependencies, and whether the abstract says why the software matters statistically.

Use these as planning ranges, not promises. JSS explicitly warns that publication times can be rather long because the journal is volunteer-run and submissions have grown. For manuscripts that pass the formal and fit checks, plan for a first substantive review in months rather than weeks; community author reports often describe long cycles, especially when software review and reproducibility checks are hard.

The calibrated range is therefore: upload and formal checks can move quickly, editor routing may take weeks, and full review can take many months because two reviewers evaluate the software and manuscript. If the package uses a less common language, has heavyweight dependencies, or lacks an easy replication path, JSS itself warns that authors may need to accept longer review times.

JSS's submission preparation checklist is unusually concrete. Submissions may be returned if authors do not adhere to the guidelines.

Common intake delays:

• PDF manuscript is not in JSS style
• source code for the software is missing or hard to read
• replication materials do not cover all manuscript results
• license is unclear or not GPL-compatible
• file size exceeds the 50 MB upload limit without external download instructions
• long manuscript exceeds 30 pages and creates predictable review-time drag
• metadata, contributors, funding, conflict-of-interest, data availability, authorship, or author-contribution details are inconsistent
• platform dependencies are not disclosed

Fix these before upload. An administrative return is not fatal, but at JSS it is expensive because the queue is already slow.

After the package clears formal intake, the editor-in-chief selects a section editor. The section editor then selects two reviewers, one of whom can be the section editor.

The first routing question is not "does the software run?" It is "is this a JSS paper?" The official guide says the typical JSS paper explains the statistical technique, the code, the actual code use, and examples, with careful discussion of existing implementations and the advantages and disadvantages of the contribution.

Strong process signals:

• abstract states the statistical-computing contribution, not only the package name
• manuscript explains the technique, implementation, examples, and comparison to alternatives
• source code is readable, documented, licensed, and package-ready
• replication materials regenerate tables, figures, simulations, and empirical examples
• examples show statistical value rather than only command syntax

Weak process signals:

• repository works but manuscript reads like package documentation
• method is solid but software is thin or unmaintained
• examples demonstrate usage without a statistical reason to care
• replication script needs manual edits, hidden data, or undocumented dependencies
• contribution belongs more naturally in JOSS, The R Journal, SoftwareX, CRAN/Bioconductor, or a methods journal

This is why the submission-process page is separate from the submission guide. The guide helps decide whether JSS is the target. The process page explains how the uploaded package is routed and reviewed.

Journal of Statistical Software triage is a paper-plus-software screen. Manuscripts that look like documentation, unreproducible packages, or method papers with a repository attached can leave the process before the authors get the review they expected.

Methodology note: this page was created from official JSS source checks, sibling-page overlap checks, and Manusights submission analysis of statistical-software manuscripts. In our analysis of JSS submission packages, the fastest process failures are visible before peer review. We evaluate the same components a section editor and software reviewers see early: abstract, introduction, examples, PDF, package files, replication script, license, documentation, and metadata.

Working software without a statistical contribution. This pattern appears when the repository is useful but the abstract and first section never explain the statistical technique, computational workflow, model class, diagnostic, simulation design, visualization, or inference problem that the software advances. JSS is not only checking whether commands run. It is checking whether the paper and software jointly advance statistical computing.

Check whether your JSS abstract states a statistical-software contribution →.

Replication material is present but not reviewer-complete. A zip file, data folder, or script is not enough if a reviewer cannot regenerate the manuscript results. The replication package should define dependencies, versions, seeds, expected outputs, runtime, platform notes, and external data. A reviewer should not have to reverse-engineer the workflow from the repository.

Check whether your JSS replication package is reviewer-complete →.

Examples show usage but not statistical value. A tutorial-style example can make the package look usable while leaving the scholarly contribution unclear. JSS examples should show why the software improves analysis, inference, diagnostics, simulation, visualization, or pedagogy compared with existing tools.

Check whether your JSS examples prove statistical value →.

The venue route is wrong. JOSS, The R Journal, SoftwareX, CRAN/Bioconductor, PyPI, Statistics and Computing, Computational Statistics, or Journal of Computational and Graphical Statistics may be better depending on whether the center is open-source software, R-community communication, software artifact, package review, or statistical method.

Our analysis of JSS submission packages treats triage as a document-and-code test. The manuscript component that fails first is usually visible before review: abstract claim, examples, package documentation, replication completeness, license clarity, or target-journal premise.

The practical pattern is specific to Journal of Statistical Software. A package can be useful and still enter the process weakly if the manuscript does not prove statistical-software value. We look for whether the abstract names the statistical problem, the introduction compares existing implementations, the examples demonstrate value, the replication script regenerates every result, and the documentation matches the paper.

We also inspect the cover letter and metadata for a journal-specific sentence: why this manuscript belongs in JSS rather than JOSS, The R Journal, SoftwareX, CRAN/Bioconductor, Statistics and Computing, Computational Statistics, or a methods journal. If that sentence is vague, the process often slows because the editor has to reconstruct the target fit.

The reviewer-count expectation is concrete. JSS says the section editor selects two reviewers, one of whom can be the section editor, and that both software and manuscript are reviewed. The review tells you whether your paper passes the same process screen editors and reviewers look for before the long review cycle starts. A paid Manusights review applies that same division before submission: statistical contribution, package usability, reproducibility, journal fit, and reviewer-risk checks. Paid reviews include the 60-day money-back guarantee, and Manusights does not train models on submitted manuscripts. We do not train on submitted manuscripts.

JSS peer review is not open peer review or a GitHub issue-style collaborative review like JOSS. It is a conventional editor-and-reviewer process with a software artifact at the center. The distinguishing feature is not single-blind visibility; it is that the reviewers evaluate both the software and the manuscript.

Reviewer assignment can slow when:

• software is written in a less common language
• the method spans statistics, machine learning, visualization, optimization, and domain science
• installation requires compiled libraries, system dependencies, or large external data
• replication takes longer than a reasonable reviewer run
• suggested reviewers are too close to the authors or too narrow in ecosystem

Once reviewers agree, they test correctness, usefulness, documentation, reproducibility, examples, and whether the manuscript explains the statistical contribution clearly.

JSS names five main decision paths.

Every revision must include a point-to-point reply to reviewers and editors. If a revision is not received within six months, JSS says the paper will be considered withdrawn. If a conditionally accepted paper is not brought into final form within a year, it will also be considered withdrawn.

The strongest author-controlled time saver is not a status email. It is a package that installs, a replication script that runs, examples that show statistical value, and a paper that is already in JSS style.

Submit to Journal of Statistical Software when:

• the paper and software jointly advance statistical computing
• the PDF is already in JSS style
• source code is readable, commented, licensed, and package-ready
• replication materials regenerate every result from the manuscript
• examples demonstrate statistical value, not only usage
• dependencies, versions, seeds, platform notes, and expected outputs are documented
• the cover letter explains why JSS is a better target than JOSS, The R Journal, SoftwareX, CRAN/Bioconductor, or a methods journal