[REVIEW]: RCzechia: Spatial Objects of the Czech Republic

editorialbot commented 1 year ago

Submitting author: !--author-handle-->@jlacko@martinfleis<!--end-editor-- Reviewers: @nickbearman, @paleolimbot Archive: 10.5281/zenodo.7665574

Status

Status badge code:

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

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) by leaving comments 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 instructions & questions

@nickbearman & @paleolimbot, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review. First of all you need to run this command in a separate comment to create the checklist:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @martinfleis know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Checklists

📝 Checklist for @nickbearman

📝 Checklist for @paleolimbot

editorialbot commented 1 year ago

Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks.

For a list of things I can do to help you, just type:

@editorialbot commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@editorialbot generate pdf

editorialbot commented 1 year ago

Software report:

github.com/AlDanial/cloc v 1.88  T=0.18 s (379.9 files/s, 21894.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
R                               55            555            825           1376
Markdown                         4            163              0            283
TeX                              1             27              0            205
YAML                             4             24             11            107
Dockerfile                       1             11             10             53
HTML                             1              1              0             15
Bourne Shell                     1              1              2              8
JSON                             2              0              0              2
Rmd                              1            100            255              0
-------------------------------------------------------------------------------
SUM:                            70            882           1103           2049
-------------------------------------------------------------------------------

gitinspector failed to run statistical information for the repository

editorialbot commented 1 year ago

Wordcount for paper.md is 1106

editorialbot commented 1 year ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1038/s41598-021-02545-z is OK
- 10.25225/jvb.21016 is OK
- 10.32614/RJ-2018-009 is OK
- 10.21105/joss.02948 is OK
- 10.5281/ZENODO.4317946 is OK
- 10.1007/s10109-020-00336-0 is OK
- 10.2307/1218258 is OK

MISSING DOIs

- None

INVALID DOIs

- None

editorialbot commented 1 year ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

martinfleis commented 1 year ago

👋🏼 @jlacko, @nickbearman, @paleolimbot this is the review thread for the paper. All of our communications will happen here from now on.

All reviewers should create checklists with the JOSS requirements using the command @editorialbot generate my checklist. As you go over the submission, please check any items that you feel have been satisfied. There are also links to the JOSS reviewer guidelines.

As you know, the JOSS review is different from most other journals. Our goal is to work with the authors to help them meet our criteria instead of merely passing judgment on the submission. As such, the reviewers are encouraged to submit issues (and small pull requests if needed) on the software repository. When doing so, please mention https://github.com/openjournals/joss-reviews/issues/5082 so that a link is created to this thread (and I can keep an eye on what is happening). Please also feel free to comment and ask questions on this thread. In my experience, it is better to post comments/questions/suggestions as you come across them instead of waiting until you've reviewed the entire package.

We aim for reviews to be completed within about 2-4 weeks, feel free to start whenever it works for you. Please let me know if any of you require significantly more time. We can also use editorialbot to set automatic reminders if you know you'll be away for a known period of time.

Given the nature of the paper, it would also be great if you can compare its functionality to previously published packages like rgugik for Polish data or tigris for the US.

Please feel free to ping me (@martinfleis) if you have any questions/concerns.

Thanks!

nickbearman commented 1 year ago

Review checklist for @nickbearman

Conflict of interest

[x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the https://github.com/jlacko/RCzechia?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Contribution and authorship: Has the submitting author (@jlacko) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[x] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
[x] Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
[x] Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
[x] Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
[x] 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

[x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

nickbearman commented 1 year ago

@jlacko I have added quite a few issues above - feel free to ask questions if they are not clear. Thanks for all of your work with this :-)

nickbearman commented 1 year ago

Re License https://github.com/jlacko/RCzechia/issues/55 there seems to be a conflict between CRAN's license requirements and JOSS's license requirements. Personally I would say I am fine with how @jlacko has approached this, but I would also like: a) a second opinion from another reviewer and/or b) a view from @martinfleis

nickbearman commented 1 year ago

@editorialbot generate pdf

editorialbot commented 1 year ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

martinfleis commented 1 year ago

there seems to be a conflict between CRAN's license requirements and JOSS's license requirements

This solution seems to be a standard way of dealing with the issue of having a human-readable License file JOSS requires as well as CRAN version. So I am fine with the solution. Thanks for pointing it out!

jlacko commented 1 year ago

I have amended the dev version of RCzechia package for the issues raised by @nickbearman. This included update of the journal article (adding library calls to code samples). I am thankful for the comments, as they led to improvement of the package for users.

I am not sure what the usual practice is, but I would like to add @nickbearman as [rev] in package description in a future version, as I really appreciated his view.

@editorialbot generate pdf

martinfleis commented 1 year ago

@editorialbot generate pdf

editorialbot commented 1 year ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

paleolimbot commented 1 year ago

Review checklist for @paleolimbot

Conflict of interest

[x] I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

[x] I confirm that I read and will adhere to the JOSS code of conduct.

General checks

[x] Repository: Is the source code for this software available at the https://github.com/jlacko/RCzechia?
[x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
[x] Contribution and authorship: Has the submitting author (@jlacko) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
[x] Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
[x] Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
[x] Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
[x] Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

[x] Installation: Does installation proceed as outlined in the documentation?
[x] Functionality: Have the functional claims of the software been confirmed?
[x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

[x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
[x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
[x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
[x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
[x] Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
[x] 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

[x] Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
[x] A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
[x] State of the field: Do the authors describe how this software compares to other commonly-used packages?
[x] Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
[x] References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

nickbearman commented 1 year ago

I have amended the dev version of RCzechia package for the issues raised by @nickbearman. This included update of the journal article (adding library calls to code samples). I am thankful for the comments, as they led to improvement of the package for users.

I am not sure what the usual practice is, but I would like to add @nickbearman as [rev] in package description in a future version, as I really appreciated his view.

Thanks @jlacko that's very kind, I really appreciate that.

nickbearman commented 1 year ago

@martinfleis I think I have now completed my review. Do let me know if I have missed any steps :-D

paleolimbot commented 1 year ago

Sorry this review took me a while to get to!

As a quick summary - this package is great! Data access packages are difficult to get right but make life so much easier...I'll note that the work that the author did here is two-fold (if I understand the workflow correctly): you've both provided cleaned up data AND written the R package to access that data (in addition to providing the hosting). The package does indeed have very high test coverage and has been on CRAN for many years (which is no small feat for a package like this one with a lot of dependencies that depends on internet access being available).

I do have some high-level suggestions having maintained a few data access packages in the past. None of these are blockers on accepting this paper.

At a very high level, many calls to functions in your paper could be replaced by (e.g.) readr::read_rds("https://rczechia.jla-data.net/"Okresy-R-2021-06.rds"). I wonder if you can lean into that a bit more (e.g., maybe printing that call or the URL when calling the function)...while calling RCzechia::okresy() is nice for interactive use and prototyping, a straight download + read_rds() might be more appropriate.
I think you should strongly consider versioning your data and encourage the version to be passed in as an argument (e.g., message saying Using okresy(version = "2023-01-01") if this version unspecified). You should have the freedom to update the data when you find a better way to clean it (or when sf updates and invalidates the object that you saved), and users should have a path to a stable dataset (e.g., to avoid surprises when rebuilding a paper that you wrote six months ago).
Providing a cache would be a nice quality of life improvement. You can see how I did it in argodata ( https://github.com/ArgoCanada/argodata/blob/master/R/zzz.R#L12-L21 )...CRAN basically won't let you specify a sane cache directory (e.g., using rappdirs) in advance so you have to make it opt-in; however, you can use a temp directory that's alive only for one R session, which is usually good enough.
Providing a configurable mirror (see the argodata link above for how I configured that too) would let you (or somebody else) test your package against an updated data source (e.g., set R_RCZECHIA_MIRROR=file://path/to/pending/change and run R CMD check).

Happy to follow up on any of those...just let me know!

jlacko commented 1 year ago

Thank you @paleolimbot for your kind words!

Regarding the high level suggestions I have a few comments, if I may:

a cache in tempdir is already implemented, lasting for current session only. A more permanent caching system was not quite feasible due to 1) CRAN policy and 2) the specifics of OSes to be supported. Tempdir is guaranteed to be present, and per session caching is enough to make life easier for users and noticeably speed up CI testing.
the implementation of the cache, together with the CRAN requirement that a connectivity failure should be handled as a message and not an error, led me to discourage the users from directly accessing the remote rds files. Instead a generic downloader function https://github.com/jlacko/RCzechia/blob/master/R/downloader.R is implemented to concentrate the logic in a single place. It first tries to serve a locally cached copy and downloads the remote file only if required.
a rudimentary versioning of rds files is implemented - several versions of the files are stored on AWS in parallel, and the path is hardcoded in R code. Meaning that to access a lower version of rds file a lower version of entire package needs to be installed.

A more performant versioning of datasets is planned, but as this will require rewriting of a lot of the internal logic I am saving this idea for a future major version. What kind of helps is that the Czech admin area definitions are not changing too fast. But it definitely is high on my list for future improvements.

I really appreciate the suggestion for a configurable mirror - the benefit to debugging is obvious, especially when linked to a local (and not remote) file location. I will certainly implement this!

martinfleis commented 1 year ago

@jlacko I see that from the standpoint of JOSS, nothing stands in the way of moving one step closer towards acceptance. Do you want to make some other changes as per suggestions or do you consider existing version ready?

jlacko commented 1 year ago

I think it would be the best to leave the article as it stands now. The short term impacts from the review process are already integrated in the development version of the package, and I will push them to CRAN shortly (hopefully with an updated citation). The more longer term impacts will require a more thorough revision of the codebase and it seems impractical to keep the article on hold for much longer.

martinfleis commented 1 year ago

@jlacko Cool!

Thank you @paleolimbot and @nickbearman for your reviews!

The submission is now almost ready to be published.

@jlacko the next steps you need to do now:

[x] Make a new tagged release (or let me know if the latest one contains all the changes) of the software, and list the version tag of the archived version here.
[x] Archive the reviewed software in Zenodo or a similar service
[x] Check that the archival deposit (e.g., in Zenodo) has the correct metadata. In particular, the title and author list should be identical to those of the paper.
[x] Please list the DOI of the archived version here.

I can then move forward with accepting the submission.

martinfleis commented 1 year ago

@editorialbot check references

martinfleis commented 1 year ago

@editorialbot generate pdf

editorialbot commented 1 year ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1038/s41598-021-02545-z is OK
- 10.25225/jvb.21016 is OK
- 10.32614/RJ-2018-009 is OK
- 10.21105/joss.02948 is OK
- 10.5281/ZENODO.4317946 is OK
- 10.1007/s10109-020-00336-0 is OK
- 10.2307/1218258 is OK

MISSING DOIs

- None

INVALID DOIs

- None

editorialbot commented 1 year ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

jlacko commented 1 year ago

Perfect; I will do that.

The current version is tagged as v1.10.2 / https://github.com/jlacko/RCzechia/releases/tag/v1.10.2

It is listed on Zenodo as https://zenodo.org/record/7665574

The metadata on Zenodo is the same as in the article / in particular the author is me (using the same ORCID as the JOSS article) and the title is the same as of the JOSS article.

The Zenodo tagged version has DOI 10.5281/zenodo.7665574

martinfleis commented 1 year ago

@editorialbot set 10.5281/zenodo.7665574 as archive

editorialbot commented 1 year ago

Done! Archive is now 10.5281/zenodo.7665574

martinfleis commented 1 year ago

@editorialbot set v1.10.2 as version

editorialbot commented 1 year ago

Done! version is now v1.10.2

martinfleis commented 1 year ago

Thanks @jlacko! That is all done from my side. I am going to recommend acceptance and pass the submission to the editor in chief.

Big thanks to @nickbearman and @paleolimbot for their reviews! We couldn't run JOSS without you!

martinfleis commented 1 year ago

@editorialbot recommend-accept

editorialbot commented 1 year ago

Attempting dry run of processing paper acceptance...

editorialbot commented 1 year ago

Couldn't check the bibtex because branch name is incorrect: joss-paper

editorialbot commented 1 year ago

:warning: Error preparing paper acceptance.

martinfleis commented 1 year ago

@editorialbot set master as branch

editorialbot commented 1 year ago

Done! branch is now master

martinfleis commented 1 year ago

@editorialbot recommend-accept

editorialbot commented 1 year ago

Attempting dry run of processing paper acceptance...

jlacko commented 1 year ago

I am sorry; this is my fault - I have closed the branch; as finalized.

editorialbot commented 1 year ago

:wave: @openjournals/sbcs-eics, this paper is ready to be accepted and published.

Check final proof :point_right::page_facing_up: Download article

If the paper PDF and the deposit XML files look good in https://github.com/openjournals/joss-papers/pull/4008, then you can now move forward with accepting the submission by compiling again with the command @editorialbot accept

editorialbot commented 1 year ago

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1038/s41598-021-02545-z is OK
- 10.25225/jvb.21016 is OK
- 10.32614/RJ-2018-009 is OK
- 10.21105/joss.02948 is OK
- 10.5281/ZENODO.4317946 is OK
- 10.1007/s10109-020-00336-0 is OK
- 10.2307/1218258 is OK

MISSING DOIs

- None

INVALID DOIs

- None

martinfleis commented 1 year ago

@jlacko no worries, that was na easy fix :)

jlacko commented 1 year ago

@martinfleis thanks for your understanding!

arfon commented 1 year ago

@editorialbot accept

editorialbot commented 1 year ago

Doing it live! Attempting automated processing of paper acceptance...

editorialbot commented 1 year ago

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

editorialbot commented 1 year ago

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/4011
Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.05082
If everything looks good, then close this review issue.
Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

openjournals / joss-reviews