Chapter 6 Guide for Authors
This concise guide presents the software peer review process for you as a package author.
- Consult our policies see if your package meets our criteria for fitting into our suite and is not overlapping with other packages.
- If you are unsure whether a package meets our criteria, feel free to open an issue as a pre-submission inquiry to ask if the package is appropriate.
- Read and follow our packaging style guide and reviewer’s guide to ensure your package meets our style and quality criteria.
- If you would like your package to also be submitted to
Journal of Open-Source Software (JOSS), it should include a
paper.mdfile describing the package. More detail on JOSS’s requirements can be found at their website.
- If you choose this option you should not submit your package to JOSS separately. It will be evaluated by JOSS based on the rOpenSci review.
- If you would like your package to also be submitted to Journal of Open-Source Software (JOSS), it should include a
- Please consider the best time in your package’s development to submit. Your package should be sufficiently mature so that reviewers are able to review all essential aspects, but keep in mind that review may result in major changes.
- For any submission or pre-submission inquiry the README of your package should provide enough information about your package (goals, usage, similar packages) for the editors to assess its scope.
- If you use repostatus.org badges (which we recommend), submit when you’re ready to get an Active instead of WIP badge. Similarly, if you use lifecycle badges, submission should happen if the package is at least Maturing.
- At the submission stage, all major functions should be stable enough to be fully documented and tested.
- We strongly suggest submitting your package for review before publishing on CRAN or submitting a software paper describing the package to a journal. Review feedback may result in major improvements and updates to your package, including renaming and breaking changes to functions.
- Your package will continue to evolve after review, this book provides guidance about the topic.
- Do not submit your package for review while it or an associated manuscript is also under review at another venue, as this may result on conflicting requests for changes.
- Next, open a new issue in the software review repository and fill out the template.
- Communication between authors, reviewers and editors will first and foremost take place on GitHub so that the review thread can serve as a full record of the review. You may choose to contact the editor by email or Slack if private consultation is needed (e.g., asking how to respond to a reviewer question). Do not contact reviewers off-thread without asking them in the GitHub thread whether they agree to it.
- When submitting a package please make sure your GitHub notification settings make it unlikely you will miss a comment.
- An editor will review your submission within 5 business days and respond with next steps. The editor may assign the package to reviewers, request that the package be updated to meet minimal criteria before review, or reject the package due to lack of fit or overlap.
- If your package meets minimal criteria, the editor will assign 1-3 reviewers. They will be asked to provide reviews as comments on your issue within 3 weeks.
- We ask that you respond to reviewers’ comments within 2 weeks of the last-submitted review, but you may make updates to your package or respond at any time. Here is an author response example. We encourage ongoing conversations between authors and reviewers. See the reviewing guide for more details.
- Once your package is approved, we will provide further instructions about the transfer of your repository to the rOpenSci repository.
Our code of conduct is mandatory for everyone involved in our review process.