Updating docs to match changes introduced in #542. Fixes #622

openjournals · Jan 1, 2020 · b04a67fb34b865e067277c029df00b6aacabe9d5 · b04a67f · danielskatz · Jan 1, 2020
1 parent 454f2e9
commit b04a67fb34b865e067277c029df00b6aacabe9d5
Unified Split

Showing with 13 additions and 12 deletions.

+6 −5 docs/review_checklist.md

+7 −7 docs/review_criteria.md
diff --git a/docs/review_checklist.md b/docs/review_checklist.md
@@ -20,8 +20,7 @@ Below is an example of the review checklist for the [Yellowbrick JOSS submission
 
 - **Repository:** Is the source code for this software available at the <a target="_blank" href="https://github.com/DistrictDataLabs/yellowbrick">repository url</a>?
 - **License:** Does the repository contain a plain-text LICENSE file with the contents of an [OSI approved](https://opensource.org/licenses/alphabetical) software license?
-- **Version:** Does the release version given match the GitHub release (v0.8)?
-- **Authorship:** Has the submitting author made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
+- **Contribution and authorship:** Has the submitting author made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
 
 ### Functionality
 
@@ -35,11 +34,13 @@ Below is an example of the review checklist for the [Yellowbrick JOSS submission
 - **Installation instructions:** Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
 - **Example usage:** Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
 - **Functionality documentation:** Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
-- **Automated tests:** Are there automated tests or manual steps described so that the function of the software can be verified?
+- **Automated tests:** Are there automated tests or manual steps described so that the functionality of the software can be verified?
 - **Community guidelines:** Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support
 
 ### Software paper
 
-- **Authors:** Does the `paper.md` file include a list of authors with their affiliations?
+- **Summary:** Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
 - **A statement of need:** Do the authors clearly state what problems the software is designed to solve and who the target audience is?
-- **References:** Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?
+- **State of the field:** Do the authors describe how this software compares to other commonly-used packages?
+- **Quality of writing:** Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
+- **References:** Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper [citation syntax]( https://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.html#citation_syntax)?
diff --git a/docs/review_criteria.md b/docs/review_criteria.md
@@ -5,12 +5,12 @@ Review criteria
 
 As outlined in the [submission guidelines provided to authors](submitting.html#what-should-my-paper-contain), the JOSS paper (the compiled PDF associated with this submission) should only include:
 
-- A list of the authors of the software
-- Author affiliations
-- A summary describing the high-level functionality and purpose of the software for a diverse, non-specialist audience
-- A clear statement of need that illustrates the purpose of the software
-- Mentions (if applicable) of any ongoing research projects using the software or recent scholarly publications enabled by it
-- A list of key references including a link to the software archive
+- A list of the authors of the software and their affiliations.
+- A summary describing the high-level functionality and purpose of the software for a diverse, non-specialist audience.
+- A clear statement of need that illustrates the purpose of the software.
+- A description of how this software compares to other commonly-used packages in this research area.
+- Mentions (if applicable) of any ongoing research projects using the software or recent scholarly publications enabled by it.
+- A list of key references including a link to the software archive.
 
 ```eval_rst
 .. important:: Note the paper *should not* include software documentation such as API (Application Programming Interface) functionality, as this should be outlined in the software documentation.
@@ -19,7 +19,7 @@ As outlined in the [submission guidelines provided to authors](submitting.html#w
 ## Review items
 
 ```eval_rst
-.. important:: Note, if you've not yet been involved in a JOSS review, you can see an example JOSS review checklist `here <review_checklist.html>`_. 
+.. important:: Note, if you've not yet been involved in a JOSS review, you can see an example JOSS review checklist `here <review_checklist.html>`_.
 ```
 
 ### Software license