Published by the Foundation for Open Access Statistics
Editors-in-chief: Bettina Grün, Torsten Hothorn, Edzer Pebesma, Achim Zeileis    ISSN 1548-7660; CODEN JSSOBK
Instructions for Authors

Instructions for Authors

The Journal of Statistical Software (JSS) is an open-source and open-access scientific journal by the statistical software community for everybody interested in statistical computing. All aspects of the journal, from editorial work over review and copy-editing up to typesetting and publication, are run by a group of volunteers committed to free software (as in software that respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes) and free-subscription, free-submission open-access publishing ideas. Therefore, and as a matter of principle, JSS charges no author fees or subscription fees. The journal does expect the same level of commitment from authors seeking to publish in JSS. Authors will have to accept a high level of responsibility throughout the whole publishing process, including the preparation of the final publishable versions of article and software. Due to the steadily increasing number of incoming and accepted submissions and limited volunteer resources, publication times can be rather long. Compliance by authors to JSS standards and instructions typically speeds-up this process considerably.

Requirements

Our mission page states what type of papers are suitable for publication in this journal.

All new submissions must provide attachments or links to

  1. PDF manuscript in JSS style,
  2. source code for the software and
  3. replication materials for all results from the manuscript, preferably via a standalone replication script.

The replication materials must enable reproducibility of all results from the manuscript (see also Review Process).

Software Preparation

Source code must be submitted in ASCII files. It should be readable and have comments. For software environments with package/library systems (e.g., R, S, Stata, etc.), the code should come with formatted help files and should be packaged for easy installation. If at all possible, submitted software should also be available from a standard repository. For R packages, we encourage inclusion of JSS submissions as vignettes. Please note that JSS only allows file uploads up to a maximum size of 50 megabyte (MB). If there is a need for bigger supplementary files, the authors should include a file containing the download instructions with a link to the external data source. If the authors do not have the resources to provide these files on an external server, please contact the JSS editors at editor@jstatsoft.org.

Code can be in any language. The majority of software published in JSS is written in S, MATLAB, SAS/IML, C++, or Java. It will be more difficult to find appropriate referees for software written in less popular languages and authors might have to accept longer review times.

Code needs to include the GNU General Public Licence (GPL), versions GPL-2 or GPL-3, or a GPL-compatible license for publication in JSS.

Manuscript Preparation

Manuscripts must be written in English using the LaTeX text processing system. The JSS style files must be used for formatting manuscript. Only PDF files can be submitted. It is the responsibility of the authors to provide a submission in the appropriate format, paying very close attention to the style instructions. Manuscripts not meeting the formal requirements will be returned to the authors immediately. JSS has no resources to help authors with conversions from other typesetting environments, so we strongly advise authors who need assistance to find a local LaTeX expert. The zip archive includes examples. Also, a manual with more detailed instructions is available for download. There is no page limit, nor a limit on the number of figures or tables. Manuscripts longer than 30 pages typically require much longer review times. However, more important for the review times incurred might be that the manuscript is carefully written exhibiting high readability.

All figures, tables, and other output presented in the manuscript must be fully and exactly reproducible on at least one platform. Please indicate any platform dependencies with the submission. Make sure to initialize the generator for pseudo random numbers if the results rely on some form of simulation. Typically, reproducibility is demonstrated by a standalone replication script. As a rough guideline, anybody with sufficient technical background should be able to install the software and to run the replication material within reasonable time.

Online Submission

Contributions are submitted online. Authors should have a look at our step-by-step submission guide.

Review Process

The software and manuscript will be peer reviewed by the statistical software community. The editor-in-chief selects a section editor, the section editor selects two reviewers (one of whom can be the section editor). The review has two parts: both the software and the manuscript are reviewed. The software should work as indicated, be clearly documented, and serve a useful purpose. Reviewers are instructed to evaluate both correctness and usefulness. Special emphasis is given on the reproducibility of the results presented in the submission.

The possible editorial decisions are:

Reject Decisions - decline (editorial reject), - reject (after review, possibly after revision) Revise Decisions - resubmit for review (will go back to both reviewers and editor), - revision required (will only go back to editor) Accept Decisions - (conditional) accept

Revisions, in any state of the review process, must always be submitted together with a point-to-point reply to the points made by reviewers and editors.

Manuscripts rejected by JSS cannot be resubmitted. We hope the review process gives the authors sufficient information to submit to another journal.

If a revision is not received back from the authors within six months of a revision being requested, the paper will be considered to be withdrawn.

If a conditionally accepted paper is not brought into final form within a year, the paper will be considered to be withdrawn.

Publishing Process

Accept decisions are always conditional on delivering a manuscript that satisfies the JSS style and reproducibility requirements. It is the responsibility of the author to make sure the manuscript conforms with the JSS requirements. Accepted manuscripts that do not satisfy these requirements cannot be published. Each published article will be a separate issue. Issues are published in volumes.

Frequently Asked Questions

  • What are the most important style guidelines in JSS?
  • What are the capitalization rules in JSS? What is title style and sentence style?
  • How to cite software?
  • How to cite R packages?
  • What are the different cite, citet, citep commands about?
  • How should abbreviations be formatted?
  • How to format figure/table captions?
  • How should code be formatted in the manuscript?
  • What is a good pen-to-paper ratio for my graphics?
  • Some of my graphics files are very large, what should I do?
  • How should my R package reflect that a manuscript about it was published in JSS?
  • How can I turn my JSS paper into an R package vignette?
  • Which naming conventions are used for software, journal, and publisher names in JSS?
  • My LaTeX paper does not compile when there is JSS markup in section titles, what should I do?
  • Compiling my LaTeX paper fails with an error at egin{document}, what went wrong?
  • Miscellaneous

What are the most important style guidelines in JSS?

The items below provide a quick style checklist for the most important style guidelines in JSS. More details can be found in the JSS style manual (jss.pdf) and in the other FAQ items.

  • The manuscript can be compiled by pdfLaTeX.
  • proglang, pkg and code have been used for highlighting throughout the paper (including titles and references), except where explicitly escaped.
  • References are provided in a .bib BibTeX database and included in the text by cite, citep, citet, etc.
  • Titles and headers are formatted as described in the JSS manual:
    • itle in title style,
    • all titles in the BibTeX file in title style.
    • section, subsection, etc. in sentence style,
    • annotations of figures/tables (including captions) in sentence style
  • Figures, tables and equations are marked with a label and referred to by ef, e.g., Figure~ ef{...}.
  • Software packes are cite{}d properly.

What are the capitalization rules in JSS? What is title style and sentence style?

In English there are basically two styles of capitalization in titles, typically referred to as "sentence style" (or "sentence case") and "title style" (or "title case"). Although there are few strict rules, the subsequent set of guidelines should be helpful.

Sentence style: Only the first word in a title is capitalized, as is the first word after a colon or a hyphen. Of course, proper names remain in upper case. A simple example would be
A fancy topic: Implementation in Java

Title style: All principal words should be capitalized. This includes the first and last words of a headline, and all nouns, pronouns, adjectives, verbs, adverbs, and subordinating conjunctions (if, because, as, that, etc.). Do capitalize the first word after a colon. Articles (a, an, the), coordinating conjunctions (and, but, or, nor, for), and prepositions of any length, are to remain lowercased. However, if any of these are the first or last word of the headline, they should be capitalized. If you have an abbreviation in your headline that is normally lowercase, it should be left lowercase, particularly abbreviations for units of measure. Two part words separated by a hyphen should have both words capitalized. Examples:

Come Join Us for a Celebration
Caring for Your Houseplants
We're Getting Ready for an Early Spring
The Forecast for Summer: Hot!
As the Wind Blows
Spraying Schedule Posted on Office Memo Board
Remember to Observe All Parking Rules
What Are They Fighting For?
A New Record: 37-in. Snow Fall Accumulation
Tick-Tock: It's Daylight Savings Time Again!

How to cite software?

Many software packages tell their users how they want to be cited, i.e., there may be a pointer on the webpage or in the manual to a suitable publication (book, journal article, technical reports, etc.). If there is no recommended citation, please cite the corresponding manual or webpage. An example is given below for SAS/STAT 9.1.

@Manual{SAS-STAT,
  author  = {{proglang{SAS} Institute Inc.}},
  title   = {proglang{SAS/STAT} Software, Version~9.1},
  year    = {2003},
  address = {Cary, NC},
  url     = {http://www.sas.com/}
}

How to cite R packages?

Please check if there is an official citation for the package. If so, this can be seen on the associated CRAN webpage, i.e., http://CRAN.R-project.org/package=foo or queried in R (if the package is installed) via citation("foo"). If there is no citation, please use a CRAN style reference as exemplified for the rJava package below.

In any case, please make sure that the BibTeX is valid, that the title is in title style and that proglang/pkg/code are used where appropriate.

@Manual{rJava,
  title  = {pkg{rJava}: Low-Level proglang{R} to proglang{Java} Interface},
  author = {Simon Urbanek},
  year   = {2009},
  note   = {proglang{R}~package version~0.8-1},
  url    = {http://CRAN.R-project.org/package=rJava},
}

What are the different cite, citet, citep commands about?

BibTeX can process citations differently and provides different commands for that. In particular, these are necessary if comments such as page references etc. should be added in brackets.

cite{...} and citet{...} yield the usual Author (Year). citep{...} yields (Author Year).

These can be modified to incorporate further text, e.g., citet[p.~123]{...} yields Author (Year, p. 123). citep[see][for further details]{...} yields (see Author Year for further details).

citealp might be useful for further flexibility, see standard LaTeX/BibTeX manuals for details.

Never use brackets-within-brackets constructs like (cite{...}).

How should abbrevations be formatted?

Abbreviations should be spelled in upper-case letters without additional formatting (i.e., without periods, without small caps, italics, etc.). All abbreviations should be introduced with their expansion where the expansion should not be capitalized. (Exceptions are, of course, when the expansion contains proper names or the first word is the first word of a sentence.) Examples would include:

support vector machine (SVM)
MCMC (Markov chain Monte Carlo)

How to format figure/table captions?

All captions should appear below the corresponding figure/table. The captions should be in sentence style and end with a period. No additional formatting (such as emph, f or it) should be used for the caption.

All table row/column headers should also be in sentence style. There should not be further footnote-style annotations in tables; these should all be placed in the caption.

How should code be formatted in the manuscript?

Code should preferably be presented in the usual text flow. It should have enough spaces to facilitate reading. Please include spaces before and after operators and after commas (unless spaces have syntactical meaning). An example would be to use

y = a + b * x

and not

y=a+b*x

The spacing should be used both for code that appears inline in the text and for code in verbatim code chunks.

The code presented in the manuscript should not contain comments within the verbatim code. Instead the comments should be made in the normal LaTeX text.

code{...} can be used for code chunks that should appear inline. Various options are available for verbatim code chunks:

  • The {Code} environment.
  • The {CodeInput}/{CodeOutput} environments.
  • For R packages the usual Sweave environments can be used. See Section 2.4 in the style manual (jss.pdf) for more details and examples.

In all cases, code input/output must fit within the normal textwidth of the manuscript. Thus, code input should have appropriate line breaks and code output should preferably be generated with a suitable width (or otherwise edited).

What is a good pen-to-paper ratio for my graphics?

JSS papers should be created in such a way that they are not only easy to read when printed on paper but also easy to read on screen. Hence, graphics should have a pen-to-paper ratio that makes them easy to read in both media. In particular, this means that annotations should not be too large or too small. As a rough guidance, graphics annotation should be a about the size of the figure caption or a little bit smaller.

A simple way of emulating increased/decreased font size in vector graphics (such as .pdf) is to just plot on a smaller/larger plotting device. When font size is kept fixed and the size of the figure as included in LaTeX is kept fixed, this will render the fonts relatively larger/smaller. (Note that a larger device will lead to relatively smaller annotation.)

Some of my graphics files are very large, what should I do?

This typically occurs when vector graphics (typically .pdf) are used for graphics with a very large amount of points or lines, e.g., in maps, heatmaps, or scatterplots with a very large amount of points. If a vector graphic is too large (i.e., larger than a few hundred kilobytes and takes a moment to load in PDF viewers), a raster graphic version of it should also be provided (.jpg or .png). It should be assured that all annotation in the raster graphic is still sufficiently easy to read (and not "pixelated").

In R, this can typically be achieved by using the png() device instead of the pdf() device. Suppose the original graphic was created by

pdf(..., height = H, width = W)

Then a useful starting point for a png() version is

png(..., height = H, width = W, units = "in", res = 144)

although higher resolutions may be needed for some graphics.

How should my R package reflect that a manuscript about it was published in JSS?

You should enhance the R package in three ways:

  • Include a reference for the JSS paper in the eferences{} section of the relevant .Rd pages.
  • Include a CITATION file in inst/CITATION within the package. A suitable file is provided by the JSS editors when the final manuscript is ready for publication.
  • Turn the JSS manuscript into a package vignette. For details see the next FAQ item.

How can I turn my JSS paper into an R package vignette?

For authors that publish their R packages in JSS we recommend:

  • Use the JSS paper as the basis for a package vignette. If you have not done so already, use Sweave-style code chunks for all input/output and graphics. See the Sweave manual for more details.
  • Turn off the JSS header and footer by using the nojss option documentclass[nojss]{jss}
  • Cite the JSS paper in the vignette (in the abstract or intro).

By doing so, the vignette is also visibly distinct from the JSS paper and you can easily extend/improve/correct the vignette in the future, keeping it up to date. For an example, see

vignette("sandwich", package = "sandwich")

Note that you do not need to include the JSS LaTeX style files in your package. They are shipped with R and installed on all relevant R servers (CRAN, R-Forge, ...).

The preferred layout can be obtained by setting

options(prompt = "R> ", continue = "+  ", width = 70, useFancyQuotes = FALSE)

invisibly in a code chunk at the beginning. (Note, however, that even though widthwas set the input/output might still be modified because width is not respected by all R functions.)

Which naming conventions are used for software, journal, and publisher names in JSS?

Software:

  • Fortran (not: FORTRAN)
  • Java (not: JAVA, java)
  • MATLAB (not: Matlab, matlab)
  • S-PLUS (not: Splus, S-Plus)

Journals:

  • The American Statistician (not: American Statistician)
  • The Annals of Statistics (not: Annals of Statistics)
  • Journal of the Royal Statistical Society B (not: Journal of the Royal Statistical Society, Series B)

Publishers:

  • Springer-Verlag (not: Springer)
  • John Wiley & Sons (not: Wiley, John Wiley & Sons Inc.)

My LaTeX paper does not compile when there is JSS markup in section titles, what should I do?

If you want to use markup in section headers you will usually have to escape it for the PDF bookmarks by giving the text for the bookmark explicitly without markup, e.g.,

section[Calling C++ from R]{Calling proglang{C++} from proglang{R}}

Compiling my LaTeX paper fails with an error at egin{document}, what went wrong?

The reason is almost surely that some of the declarations in the header have not been made properly. For example, Plainauthor, Plaintitle or Plainkeywords might be missing or still containing markup.

Miscellaneous

Below is a list of miscellaneous style conventions used in JSS:

  • For referring to subsections, do not use Subsection x.y, just Section x.y.
  • When using e.g. and i.e. add a comma after the period to keep LaTeX from interpreting them as the end of a sentence, i.e.: e.g., and i.e., .
  • House style is to use $p$~value, $t$~statistic$, etc. (without hyphen).
  • op should be used as the transpose symbol, e.g., X^ op.
  • For R-related manuscripts: The first argument of data() and library() should always be quoted, e.g., library("foo").
  • For books with an edition, this should be indicated as 2nd, 3rd, etc.
  • To refer to equations, one can use either Equation~ ef{...} (with capitalization) or ( ef{...}) with the former being preferred if the number of equation references is not too large.