Submitting author: @cvitolo (Claudia Vitolo)
Repository: https://github.com/kehraProject/r_rdefra
Version: v0.3.0
Editor: @arfon
Reviewer: @pragyansmita
Archive: 10.5281/zenodo.61033

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/57058f6e8a511f3bb0667ef7687cc87d"><img src="http://joss.theoj.org/papers/57058f6e8a511f3bb0667ef7687cc87d/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/57058f6e8a511f3bb0667ef7687cc87d/status.svg)](http://joss.theoj.org/papers/57058f6e8a511f3bb0667ef7687cc87d)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.3.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00051.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @dfm (Daniel Foreman-Mackey)
Repository: https://github.com/dfm/corner.py
Version: v2.0.0
Editor: @arfon
Reviewer: @tacaswell
Archive: http://dx.doi.org/10.5281/zenodo.53155

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/960cad70e806f6fc9760888d64dc2c72"><img src="http://joss.theoj.org/papers/960cad70e806f6fc9760888d64dc2c72/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/960cad70e806f6fc9760888d64dc2c72/status.svg)](http://joss.theoj.org/papers/960cad70e806f6fc9760888d64dc2c72)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v2.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00024.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @zhaozhang (Zhao Zhang)
Repository: https://github.com/applicationskeleton/Skeleton
Version: v1.2
Editor: @arfon
Reviewer: @krother
Archive: http://dx.doi.org/10.5281/zenodo.13750

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/6b34fdbf8215c1ecd4941afc8be7a7e6"><img src="http://joss.theoj.org/papers/6b34fdbf8215c1ecd4941afc8be7a7e6/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/6b34fdbf8215c1ecd4941afc8be7a7e6/status.svg)]http://joss.theoj.org/papers/6b34fdbf8215c1ecd4941afc8be7a7e6

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.2)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: paper.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

I was just looking a newly submitted paper and wondered whether it actually addresses a research question, i.e., its academic value. I think we should add a standard reviewer question that says something about that. It is a box that needs to be ticked if we want to be taken seriously as a scientific journal. We don't want JOSS to end up as a basket for software projects that have no academic value.

Submitting author: @eddelbuettel (Dirk Eddelbuettel)
Repository: https://github.com/eddelbuettel/rcppcnpy
Version: 0.2.5
Editor: @cMadan
Reviewer: @mdnunez
Archive: 10.5281/zenodo.155066

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/6afd88394721d1f421f5a023467a8b86"><img src="http://joss.theoj.org/papers/6afd88394721d1f421f5a023467a8b86/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/6afd88394721d1f421f5a023467a8b86/status.svg)](http://joss.theoj.org/papers/6afd88394721d1f421f5a023467a8b86)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.2.5)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00055.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @PeteHaitch (Peter Hickey)
Repository: https://github.com/PeteHaitch/GenomicTuples
Version: v1.7.3
Editor: @arfon
Reviewer: @amoeba
Archive: http://dx.doi.org/10.5281/zenodo.53186

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/64b99f363d24b8a7e9025188183e9865"><img src="http://joss.theoj.org/papers/64b99f363d24b8a7e9025188183e9865/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/64b99f363d24b8a7e9025188183e9865/status.svg)](http://joss.theoj.org/papers/64b99f363d24b8a7e9025188183e9865)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.7.2)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00020.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @sbogutzky (Simon Bogutzky)
Repository: https://github.com/sbogutzky/PsychoPhysioPipeline
Branch with paper.md (empty if default branch):
Version: v2.0.0
Editor: @arfon
Reviewers: @davclark
Archive: 10.5281/zenodo.61965

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/6eb8fe64344fa4671a66f49eed43fad5"><img src="http://joss.theoj.org/papers/6eb8fe64344fa4671a66f49eed43fad5/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/6eb8fe64344fa4671a66f49eed43fad5/status.svg)](http://joss.theoj.org/papers/6eb8fe64344fa4671a66f49eed43fad5)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v2.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00041.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @sdwfrost (Simon Frost)
Repository: http://github.com/sdwfrost/Gillespie.jl
Version: v0.0.1
Editor: @arfon
Reviewer: @vchuravy
Archive: 10.5281/zenodo.59127

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/3cfdd80b93a9123b173e9617c1e6a238"><img src="http://joss.theoj.org/papers/3cfdd80b93a9123b173e9617c1e6a238/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/3cfdd80b93a9123b173e9617c1e6a238/status.svg)](http://joss.theoj.org/papers/3cfdd80b93a9123b173e9617c1e6a238)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.0.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00042.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @desilinguist (Nitin Madnani)
Repository: https://github.com/EducationalTestingService/rsmtool
Version: v5.1.0
Editor: @arfon
Reviewer: @jkahn
Archive: 10.5281/zenodo.58851

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/fbc649c17d45074d92ac21084aaa6209"><img src="http://joss.theoj.org/papers/fbc649c17d45074d92ac21084aaa6209/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/fbc649c17d45074d92ac21084aaa6209/status.svg)](http://joss.theoj.org/papers/fbc649c17d45074d92ac21084aaa6209)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v5.0.2)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00033.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @cMadan (Christopher R Madan)
Repository: https://github.com/cMadan/prism
Version: v2.0.0
Editor: @arfon
Reviewer: @Kevin-Mattheus-Moerman
Archive: http://dx.doi.org/10.5281/zenodo.56821

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/c73c191e5a4ac34b12b0bfc6237a2202"><img src="http://joss.theoj.org/papers/c73c191e5a4ac34b12b0bfc6237a2202/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/c73c191e5a4ac34b12b0bfc6237a2202/status.svg)](http://joss.theoj.org/papers/c73c191e5a4ac34b12b0bfc6237a2202)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v2.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00031.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @pjotrp (Pjotr Prins)
Repository: https://github.com/genenetwork/genenetwork2
Version: 2.0-a8fcff4
Editor: @arfon
Reviewer: @krother, @agarie
Archive: 10.5281/zenodo.53740

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/84b27b28948be80a47268a5baa2701ad"><img src="http://joss.theoj.org/papers/84b27b28948be80a47268a5baa2701ad/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/84b27b28948be80a47268a5baa2701ad/status.svg)](http://joss.theoj.org/papers/84b27b28948be80a47268a5baa2701ad)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (2.0-a8fcff4)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00025.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @SebastianBocquet (Sebastian Bocquet)
Repository: https://github.com/SebastianBocquet/pygtc
Version: 0.1.1
Editor: @arfon
Reviewer: @dfm
Archive: https://dx.doi.org/10.5281/zenodo.159225

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/fac5017b39292e539933d12936615f4a"><img src="http://joss.theoj.org/papers/fac5017b39292e539933d12936615f4a/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/fac5017b39292e539933d12936615f4a/status.svg)](http://joss.theoj.org/papers/fac5017b39292e539933d12936615f4a)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.1.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00046.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @juliasilge (Julia Silge)
Repository: https://github.com/juliasilge/tidytext
Version: v0.1.1
Editor: @arfon
Reviewer: @rmflight
Archive: http://dx.doi.org/10.5281/zenodo.56714

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/89fd1099620268fe0342ffdcdf66776f"><img src="http://joss.theoj.org/papers/89fd1099620268fe0342ffdcdf66776f/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/89fd1099620268fe0342ffdcdf66776f/status.svg)](http://joss.theoj.org/papers/89fd1099620268fe0342ffdcdf66776f)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.1.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00037.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @n3mo (Nicholas Van Horn)
Repository: https://github.com/n3mo/massmine
Version: v1.0.1
Editor: @mgymrek
Reviewer: @julianmcauley
Archive: 10.5281/zenodo.193078

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/bcbd89b81c517e5123fc1cfa80501ae7"><img src="http://joss.theoj.org/papers/bcbd89b81c517e5123fc1cfa80501ae7/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/bcbd89b81c517e5123fc1cfa80501ae7/status.svg)](http://joss.theoj.org/papers/bcbd89b81c517e5123fc1cfa80501ae7)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00050.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @sbogutzky (Simon Bogutzky)
Repository: https://github.com/sbogutzky/PsychoPhysioCollector
Version: v2.0.5
Editor: @arfon
Reviewer: @davclark
Archive: 10.5281/zenodo.59387

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/aacbdea63ce8d4896a3c84d89f4c5ee0"><img src="http://joss.theoj.org/papers/aacbdea63ce8d4896a3c84d89f4c5ee0/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/aacbdea63ce8d4896a3c84d89f4c5ee0/status.svg)](http://joss.theoj.org/papers/aacbdea63ce8d4896a3c84d89f4c5ee0)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v2.0.4)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00040.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Firefox 46.0.1 on Mac OS X 10.10.5, Markdown summaries on home page are not rendered properly:

Submitting author: @markus2330 (Markus Raab)
Repository: https://github.com/ElektraInitiative/libelektra
Version: 0.8.17
Editor: @danielskatz
Reviewer: @eschnett
Archive: 10.5281/zenodo.200894

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/abf25701c0113483bf2f3e3d4dac13d3"><img src="http://joss.theoj.org/papers/abf25701c0113483bf2f3e3d4dac13d3/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/abf25701c0113483bf2f3e3d4dac13d3/status.svg)](http://joss.theoj.org/papers/abf25701c0113483bf2f3e3d4dac13d3)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.8.17)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00044.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Firefox 46.0.1 on Mac OS X 10.10.5, top of 'about' page is clipped:

Submitting author: @michaellevy (Michael Levy)
Repository: https://github.com/michaellevy/gwdegree
Version: v0.1.1
Editor: @arfon
Reviewer: @amoeba
Archive: http://dx.doi.org/10.5281/zenodo.57495

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/0f4eda35180f77176ce495cd4d711075"><img src="http://joss.theoj.org/papers/0f4eda35180f77176ce495cd4d711075/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/0f4eda35180f77176ce495cd4d711075/status.svg)](http://joss.theoj.org/papers/0f4eda35180f77176ce495cd4d711075)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.1.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00036.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @rodrigovrgs (Rodrigo Honorato)
Repository: https://github.com/rodrigovrgs/cazy-parser
Version: v1.0
Editor: @pjotrp
Reviewer: @luizirber
Archive: 10.5281/zenodo.200893

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/f709afe5d720fc6eee82fca277942a46"><img src="http://joss.theoj.org/papers/f709afe5d720fc6eee82fca277942a46/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/f709afe5d720fc6eee82fca277942a46/status.svg)](http://joss.theoj.org/papers/f709afe5d720fc6eee82fca277942a46)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00053.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @rCarto (Timothée Giraud)
Repository: https://github.com/Groupe-ElementR/cartography
Version: v1.4.0
Editor: @arfon
Reviewer: @jankatins
Archive: 10.5281/zenodo.60878

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/0c2d51fc23efb8e1f87d764da8414923"><img src="http://joss.theoj.org/papers/0c2d51fc23efb8e1f87d764da8414923/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/0c2d51fc23efb8e1f87d764da8414923/status.svg)](http://joss.theoj.org/papers/0c2d51fc23efb8e1f87d764da8414923)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.4.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00054.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @cvitolo (Claudia Vitolo)
Repository: https://github.com/cvitolo/fuse
Version: v3.0.0
Editor: @arfon
Reviewer: @masalmon
Archive: 10.5281/zenodo.212822

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/392a55daada04a86f95eaa8da134a28d"><img src="http://joss.theoj.org/papers/392a55daada04a86f95eaa8da134a28d/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/392a55daada04a86f95eaa8da134a28d/status.svg)](http://joss.theoj.org/papers/392a55daada04a86f95eaa8da134a28d)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v3.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00052.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @genomematt (Matthew J Wakefield)
Repository: http://github.com/genomematt/xenomapper/
Version: v1.0.1
Editor: @arfon
Reviewer: @xuanxu
Archive: 10.5281/zenodo.51798

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/7065e20e97ff4e44695b5e9fef7cdcd8"><img src="http://joss.theoj.org/papers/7065e20e97ff4e44695b5e9fef7cdcd8/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/7065e20e97ff4e44695b5e9fef7cdcd8/status.svg)](http://joss.theoj.org/papers/7065e20e97ff4e44695b5e9fef7cdcd8)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.1)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00018.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @meyera (Alexander Meyer)
Repository: https://github.com/meyera/riskscorer
Version: v0.2.0
Archive: http://dx.doi.org/10.5281/zenodo.51342
Editor: @arfon
Reviewer: @maelle

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/b6fca2486948af8ebd56fc31fc7277c3"><img src="http://joss.theoj.org/papers/b6fca2486948af8ebd56fc31fc7277c3/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/b6fca2486948af8ebd56fc31fc7277c3/status.svg)](http://joss.theoj.org/papers/b6fca2486948af8ebd56fc31fc7277c3)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.2.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00019.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @drcassar (Daniel Cassar)
Repository: https://github.com/drcassar/TPIB
Version: v1.0.0
Editor: @kyleniemeyer
Reviewer: @nicoguaro
Archive: Pending

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/c33ddde3bc1bedc615cbdc99d656c7e5"><img src="http://joss.theoj.org/papers/c33ddde3bc1bedc615cbdc99d656c7e5/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/c33ddde3bc1bedc615cbdc99d656c7e5/status.svg)](http://joss.theoj.org/papers/c33ddde3bc1bedc615cbdc99d656c7e5)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00049.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @Samreay (Samuel Hinton)
Repository: https://github.com/samreay/ChainConsumer
Version: 0.10.1
Editor: @arfon
Reviewer: @tacaswell
Archive: 10.5281/zenodo.61064

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/e8496ffefaece1e7614a24cc86b0535b"><img src="http://joss.theoj.org/papers/e8496ffefaece1e7614a24cc86b0535b/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/e8496ffefaece1e7614a24cc86b0535b/status.svg)](http://joss.theoj.org/papers/e8496ffefaece1e7614a24cc86b0535b)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.9.5)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00045.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @zoran-cuckovic (Zoran Čučković)
Repository: https://github.com/zoran-cuckovic/QGIS-visibility-analysis
Version: 0.5.1
Editor: @arfon
Reviewer: @robintw
Archive: 10.5281/zenodo.59896

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/a8f76eeda4f92e7d641757dd0d7ed7f5"><img src="http://joss.theoj.org/papers/a8f76eeda4f92e7d641757dd0d7ed7f5/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/a8f76eeda4f92e7d641757dd0d7ed7f5/status.svg)](http://joss.theoj.org/papers/a8f76eeda4f92e7d641757dd0d7ed7f5)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.5.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00032.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @hrbrmstr (Bob Rudis)
Repository: https://github.com/hrbrmstr/metricsgraphics
Version: v0.9.1
Archive: 10.5281/zenodo.50373
Editor: @arfon
Reviewer: @amoeba

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/1677676c38bd118db5fe363a6eb3f88f"><img src="http://joss.theoj.org/papers/1677676c38bd118db5fe363a6eb3f88f/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/1677676c38bd118db5fe363a6eb3f88f/status.svg)]http://joss.theoj.org/papers/1677676c38bd118db5fe363a6eb3f88f

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.9.1)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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?
• 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)?

Submitting author: @kbarbary (Kyle Barbary)
Repository: https://github.com/kbarbary/sep
Version: v1.0.0
Editor: @arfon
Reviewer: @danielskatz
Archive: http://dx.doi.org/10.5281/zenodo.159035

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b"><img src="http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b/status.svg)](http://joss.theoj.org/papers/aa9bcf7c898895f5338ef5934f99061b)

Reviewers and authors: Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue
in the target repository and link to those issues (especially acceptance-blockers)
in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice
versa will create corresponding breadcrumb trails in the link target.)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.6.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00058.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Firefox 46.0.1 on Mac OS X 10.10.5: small character icons (?) beside titles are showing up as unrenderable.

Submitting author: @charalambos (Charalambos Poullis)
Repository: https://github.com/theICTlab/3DUNDERWORLD-SLS-GPU_CPU
Version: v4.0.0
Editor: @Kevin-Mattheus-Moerman
Reviewer: @daviddoria
Archive: Pending

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/4329bcbc7bba33961a5e749dcacb995b"><img src="http://joss.theoj.org/papers/4329bcbc7bba33961a5e749dcacb995b/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/4329bcbc7bba33961a5e749dcacb995b/status.svg)](http://joss.theoj.org/papers/4329bcbc7bba33961a5e749dcacb995b)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v4.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00047.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @SimonGreenhill (Simon Greenhill)
Repository: https://github.com/SimonGreenhill/phylogemetric
Version: v1.0.0
Editor: @arfon
Reviewer: @krother
Archive: http://dx.doi.org/10.5281/zenodo.55663

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/a5ebf008ebed6616b939c53e02f1038f"><img src="http://joss.theoj.org/papers/a5ebf008ebed6616b939c53e02f1038f/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/a5ebf008ebed6616b939c53e02f1038f/status.svg)](http://joss.theoj.org/papers/a5ebf008ebed6616b939c53e02f1038f)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00028.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @labarba (Lorena A. Barba)
Repository: https://github.com/barbagroup/pygbe
Version: 2.1
Editor: @arfon
Reviewer: @kyleniemeyer
Archive: 10.5281/zenodo.60474

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/73fcd8f3fcc262db670ec8fccfdad706"><img src="http://joss.theoj.org/papers/73fcd8f3fcc262db670ec8fccfdad706/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/73fcd8f3fcc262db670ec8fccfdad706/status.svg)](http://joss.theoj.org/papers/73fcd8f3fcc262db670ec8fccfdad706)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.2)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00043.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @harpolea (Alice Harpole)
Repository: https://github.com/harpolea/r3d2
Editor: @arfon
Reviewer: @kyleniemeyer
Version: v1.0

Archive: http://dx.doi.org/10.5281/zenodo.51096

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/99f57be50022ae8b2eecdd1d28b05766"><img src="http://joss.theoj.org/papers/99f57be50022ae8b2eecdd1d28b05766/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/99f57be50022ae8b2eecdd1d28b05766/status.svg)]http://joss.theoj.org/papers/99f57be50022ae8b2eecdd1d28b05766

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00016.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @germonprez (Matt Germonprez)
Repository: https://github.com/DoSOCSv2/DoSOCSv2
Version: 0.16.1
Editor: @arfon
Reviewer: @mlinksva
Archive: https://dx.doi.org/10.6084/m9.figshare.4239665.v1

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/047ccda9fe1143c7cbe8a7341cb41d2e"><img src="http://joss.theoj.org/papers/047ccda9fe1143c7cbe8a7341cb41d2e/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/047ccda9fe1143c7cbe8a7341cb41d2e/status.svg)](http://joss.theoj.org/papers/047ccda9fe1143c7cbe8a7341cb41d2e)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.16.1)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00038.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @ctb (C. Titus Brown)
Repository: https://github.com/dib-lab/sourmash/
Version: 1.0
Editor: @arfon
Reviewer: @jkahn
Archive: 10.5281/zenodo.153989

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/3d793c6e7db683bee7c03377a4a7f3c9"><img src="http://joss.theoj.org/papers/3d793c6e7db683bee7c03377a4a7f3c9/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/3d793c6e7db683bee7c03377a4a7f3c9/status.svg)](http://joss.theoj.org/papers/3d793c6e7db683bee7c03377a4a7f3c9)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (0.9.2)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00027.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @karantibrewal (Karan Tibrewal)
Repository: https://github.com/knightsay/backtestGraphics
Version: v1.0.0
Editor: @arfon
Reviewer: @joshuaulrich

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/625ee3e1e9007c3c1aae2f8c8b3f7f92"><img src="http://joss.theoj.org/papers/625ee3e1e9007c3c1aae2f8c8b3f7f92/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/625ee3e1e9007c3c1aae2f8c8b3f7f92/status.svg)](http://joss.theoj.org/papers/625ee3e1e9007c3c1aae2f8c8b3f7f92)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00030.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @vpnagraj (VP Nagraj)
Repository: https://github.com/vpnagraj/grupo
Version: v1.0.0
Archive: https://dx.doi.org/10.6084/m9.figshare.3383653.v1
Editor: @arfon
Reviewer: @aespinosa

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/3f833ae46924e1e79582c3715eb38496"><img src="http://joss.theoj.org/papers/3f833ae46924e1e79582c3715eb38496/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/3f833ae46924e1e79582c3715eb38496/status.svg)](http://joss.theoj.org/papers/3f833ae46924e1e79582c3715eb38496)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00022.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @cvitolo (Claudia Vitolo)
Repository: https://github.com/ropensci/hddtools/
Version: v0.3.0
Editor: @arfon
Reviewer: @karthik
Archive: https://dx.doi.org/10.5281/zenodo.247842

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/3287a12e7ce5d7e89938a6b4f56fc225"><img src="http://joss.theoj.org/papers/3287a12e7ce5d7e89938a6b4f56fc225/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/3287a12e7ce5d7e89938a6b4f56fc225/status.svg)](http://joss.theoj.org/papers/3287a12e7ce5d7e89938a6b4f56fc225)

Reviewers and authors: Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue
in the target repository and link to those issues (especially acceptance-blockers)
in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice
versa will create corresponding breadcrumb trails in the link target.)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.3.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00056.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @glouppe (Gilles Louppe)
Repository: https://github.com/diana-hep/carl
Version: v0.2
Editor: @arfon
Reviewer: @betatim
Archive: 10.5281/zenodo.47798

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/26a9ffd9e7b98b1911d89d2ceb268f37"><img src="http://joss.theoj.org/papers/26a9ffd9e7b98b1911d89d2ceb268f37/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/26a9ffd9e7b98b1911d89d2ceb268f37/status.svg)](http://joss.theoj.org/papers/26a9ffd9e7b98b1911d89d2ceb268f37)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v0.2)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• [ ] Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is? diana-hep/carl#53
• 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 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?
• 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 diana-hep/carl#53

Software paper

• Authors: Does the paper.md file include a list of authors with their affiliations?
• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is? diana-hep/carl#53
• References: Do all archival references that should have a DOI list one (e.g. papers, datasets, software)?

Submitting author: @jiemakel (Eetu Mäkelä)
Repository: https://github.com/jiemakel/las
Version: v1.4.8
Editor: @arfon
Reviewer: @desilinguist
Archive: https://dx.doi.org/10.5281/zenodo.160256

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/87f0093e30a01b1078d8dea41476a08a"><img src="http://joss.theoj.org/papers/87f0093e30a01b1078d8dea41476a08a/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/87f0093e30a01b1078d8dea41476a08a/status.svg)](http://joss.theoj.org/papers/87f0093e30a01b1078d8dea41476a08a)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.4.8)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00035.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @ctjacobs (Christian T. Jacobs)
Repository: https://github.com/ctjacobs/git-rdm
Version: v1.0.0
Editor: @arfon
Reviewer: @jsta
Archive: 10.6084/m9.figshare.3443750.v1

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/d0641341031a50d63d61e6149768d19e"><img src="http://joss.theoj.org/papers/d0641341031a50d63d61e6149768d19e/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/d0641341031a50d63d61e6149768d19e/status.svg)](http://joss.theoj.org/papers/d0641341031a50d63d61e6149768d19e)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00029.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @alk224 (Andrew Krohn)
Repository: https://github.com/alk224/akutils-v1.2
Version: v1.2.3
Editor: @arfon
Reviewer: @serine

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/00608bdd0dcee9c442427f3d8c1c5def"><img src="http://joss.theoj.org/papers/00608bdd0dcee9c442427f3d8c1c5def/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/00608bdd0dcee9c442427f3d8c1c5def/status.svg)](http://joss.theoj.org/papers/00608bdd0dcee9c442427f3d8c1c5def)

Reviewers and authors: Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue
in the target repository and link to those issues (especially acceptance-blockers)
in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice
versa will create corresponding breadcrumb trails in the link target.)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.2.3)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00057.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @jakevdp (Jacob VanderPlas)
Repository: http://github.com/jakevdp/mst_clustering
Version: v1.0.0
Editor: @arfon
Reviewer: @nicoguaro
Archive: http://dx.doi.org/10.5281/zenodo.50995

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/0b73d249cd34985b6fa1a5ad4f4f8014"><img src="http://joss.theoj.org/papers/0b73d249cd34985b6fa1a5ad4f4f8014/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/0b73d249cd34985b6fa1a5ad4f4f8014/status.svg)]http://joss.theoj.org/papers/0b73d249cd34985b6fa1a5ad4f4f8014

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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?
• 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)?

Submitting author: @conradsnicta (Conrad Sanderson)
Repository: https://github.com/conradsnicta/armadillo/
Version: v7.200.1b
Editor: @arfon
Reviewer: @wrathematics
Archive: 10.5281/zenodo.55251

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/4d6506e46a96659b74f48b51ef92fa93"><img src="http://joss.theoj.org/papers/4d6506e46a96659b74f48b51ef92fa93/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/4d6506e46a96659b74f48b51ef92fa93/status.svg)](http://joss.theoj.org/papers/4d6506e46a96659b74f48b51ef92fa93)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v7.200.1b)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Paper PDF: 10.21105.joss.00026.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @jtauber (James Tauber)
Repository: https://github.com/jtauber/pyuca
Version: v1.1.2
Editor: @arfon
Reviewer: @luizirber
Archive: 10.5281/zenodo.51622

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/28430167d67c58585f014e503baf6f08"><img src="http://joss.theoj.org/papers/28430167d67c58585f014e503baf6f08/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/28430167d67c58585f014e503baf6f08/status.svg)](http://joss.theoj.org/papers/28430167d67c58585f014e503baf6f08)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.1.1)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00021.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @balhoff (James P. Balhoff)
Repository: https://github.com/phenoscape/scowl
Version: v1.1
Editor: @arfon
Reviewer: @xuanxu
Archive: http://dx.doi.org/10.5281/zenodo.51556

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/1b9d09aab8754997884a04c081cfc019"><img src="http://joss.theoj.org/papers/1b9d09aab8754997884a04c081cfc019/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/1b9d09aab8754997884a04c081cfc019/status.svg)](http://joss.theoj.org/papers/1b9d09aab8754997884a04c081cfc019)

Reviewer questions

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.1)?
• Archive: Does the software archive resolve?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have the performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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 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?
• 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

Compiled paper PDF: 10.21105.joss.00023.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: @cxhernandez (Carlos Xavier Hernández)
Repository: https://github.com/msmbuilder/osprey
Version: v1.1.0
Editor: @arfon
Reviewer: @rasbt
Archive: 10.5281/zenodo.61670

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/659cfc3ec56b30c607f705983e592406"><img src="http://joss.theoj.org/papers/659cfc3ec56b30c607f705983e592406/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/659cfc3ec56b30c607f705983e592406/status.svg)](http://joss.theoj.org/papers/659cfc3ec56b30c607f705983e592406)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.0.0)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00034.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?

Submitting author: JonathanAMichaels (Jonathan A Michaels)
Repository: https://github.com/JonathanAMichaels/hebbRNN
Version: v1.2
Editor: @arfon
Reviewer: @cMadan
Archive: 10.5281/zenodo.154745

Status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/03d299789d8d6b633e648342b4454dca"><img src="http://joss.theoj.org/papers/03d299789d8d6b633e648342b4454dca/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/03d299789d8d6b633e648342b4454dca/status.svg)](http://joss.theoj.org/papers/03d299789d8d6b633e648342b4454dca)

Reviewers and authors: Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue
in the target repository and link to those issues (especially acceptance-blockers)
in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice
versa will create corresponding breadcrumb trails in the link target.)

Reviewer questions

Conflict of interest

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (such as being a major contributor to the software).

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Version: Does the release version given match the GitHub release (v1.2)?

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: Have any performance claims of the software been confirmed?

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• 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?
• 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

Paper PDF: 10.21105.joss.00060.pdf

• Authors: Does the paper.md file include a list of authors with their affiliations?
• 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)?