Giters

ropensci / software-review

rOpenSci Software Peer Review.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Submission: hydroscoper

kvantas opened this issue · comments

commented

Summary

  • What does this package do? (explain in 50 words or less):
    hydroscoper is an interface to the Greek National Data Bank for Hydrological and Meteorological Information, Hydroscope. It provides functions to: a) Transform the available tables and data sets into tidy data frames. b) Transliterate the Greek Unicode text to Latin. c) Translate various Greek terms to English.

  • Paste the full DESCRIPTION file inside a code block below:

Package: hydroscoper
Type: Package
Title: Interface to Hydroscope
Version: 0.2.1
Authors@R: person("Konstantinos", "Vantas", role = c("aut", "cre"),
  email = "kon.vantas@gmail.com",
  comment = c(ORCID = "0000-0001-6387-8791"))
Maintainer: Konstantinos Vantas <kon.vantas@gmail.com>
Description: R interface to the  Greek National Data Bank for Hydrological and 
    Meteorological Information <http://www.hydroscope.gr/>. It 
    covers Hydroscope's data sources and provides functions to transliterate, 
    translate and download them into tidy dataframes (tibbles).
URL: https://github.com/kvantas/hydroscoper
BugReports: https://github.com/kvantas/hydroscoper/issues             
Depends: R (>= 3.4.0)
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
RoxygenNote: 6.0.1
Imports: stringi (>= 1.1.6),
    stringr (>= 1.2), 
    tibble(>= 1.4.1),
    readr (>= 1.1.1),
    jsonlite (>= 1.5),
Suggests: plyr (>= 1.8.4),
    ggplot2 (>= 2.2.1),
    knitr (>= 1.17),
    rmarkdown (>= 1.8),
    testthat (>= 1.0.2),
    ggmap (>= 2.6.1)
VignetteBuilder: knitr

  • URL for the package (the development repository, not a stylized html page):
    https://github.com/kvantas/hydroscoper

  • Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):
    data retrieval, because the package parses and download data from a national data-bank.

  •   Who is the target audience and what are scientific applications of this package?  
    a) Engineers for the development of water resources and environmental studies in Greece, b) scientists that work with hydrological and meteorological data from Hydroscope and c) Greek organizations to submit data and reports to the European Union for the Implementation of the Water Framework Directive.

  • Are there other R packages that accomplish the same thing? If so, how does
    yours differ or meet our criteria for best-in-category?
    No other package exists.

  •   If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

Requirements

Confirm each of the following by checking the box. This package:

  • does not violate the Terms of Service of any service it interacts with.
  • has a CRAN and OSI accepted license.
  • contains a README with instructions for installing the development version.
  • includes documentation with examples for all functions.
  • contains a vignette with examples of its essential functions and uses.
  • has a test suite.
  • has continuous integration, including reporting of test coverage, using services such as Travis CI, Coveralls and/or CodeCov.
  • I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

  • Do you intend for this package to go on CRAN? (allready on CRAN)
  • Do you wish to automatically submit to the Journal of Open Source Software? If so:
    • The package has an obvious research application according to JOSS's definition.
    • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
    • The package is deposited in a long-term repository with the DOI: 10.5281/zenodo.1120431
    • (Do not submit your package separately to JOSS)
  • Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:
    • The package is novel and will be of interest to the broad readership of the journal.
    • The manuscript describing the package is no longer than 3000 words.
    • You intend to archive the code for the package in a long-term repository which meets the requirements of the journal.
    • (Please do not submit your package separately to Methods in Ecology and Evolution)

Detail

  • Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:
R CMD check results
0 errors | 0 warnings | 0 notes

  • Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

  • If this is a resubmission following rejection, please explain the change in circumstances:

  • If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

commented

using cover::package_coverage() using local tests (i.e. comment line 20 in file /test/test_get.R) I get:

hydroscoper Coverage: 98.94%
R/get_data.R: 90.91%
R/enhydris.R: 98.04%
R/defunct.R: 100.00%
R/get_tables.R: 100.00%
R/hydro_coords.R: 100.00%
R/hydro_translate.R: 100.00%
R/translit.R: 100.00%

and with goodpractice::gp():

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 98% of code
    lines are covered by test cases.

    R/enhydris.R:77:NA
    R/get_data.R:64:NA
commented

Editor checks:

  • Fit: The package meets criteria for fit and overlap
  • Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
  • License: The package has a CRAN or OSI accepted license
  • Repository: The repository link resolves correctly
  • Archive (JOSS only, may be post-review): The repository DOI resolves correctly
  • Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

Editor comments

Thanks for your submission, @kvantas! 😸 My only note for you and the reviewers is the error handling of that deh subdomain. I'll erase a few comments to keep the thread clean.

Reviewers: @timtrice shargelfand
Due date: 2018-02-04 & 2018-02-21 respectively

commented

@timtrice thanks for accepting to review this package! 😄

Your review is due on 2018-02-04.

Please find here our reviewing guide and the review template.

commented

Following @maelle 's advice I enriched error handling about all the sub-domains availability. Thank you very much!

commented

@kvantas for info one of the two reviewers had to drop out this time, so the second reviewer will be @sharlagelfand.

@sharlagelfand, thanks for accepting to review this package! Your review is due on 2018-02-21. 😸

Please find here our reviewing guide and the review template.

commented

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:

Review Comments

  1. Failed to parse URL (from vignette):
library(hydroscoper)
library(plyr)
subdomain <- "kyy"
stations <- get_stations(subdomain)
coords  <- ldply(stations$StationID, function(id) {get_coords(subdomain, id)})
Warning messages:
1: Failed to parse url: http://kyy.hydroscope.gr/stations/d/501032/
 
2: Failed to parse url: http://kyy.hydroscope.gr/stations/d/200425/
 
3: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10014/

timeseries <- ldply(stations$StationID, function(id) {get_timeseries(subdomain, id)})
Warning messages:
1: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10003/
 
2: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10004/
 
3: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10005/
 
4: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10006/
 
5: Failed to parse url: http://kyy.hydroscope.gr/stations/d/10014/

  1. Should contribution guidelines be named CONTRIBUTING.md rather than CONDUCT.md? (@maelle )

  2. I am unsure about the JOSS questions with the exception that the package does not have a paper.md file as listed (@maelle)

  3. I would recommend using the @title, @description, @details and @section tags in function documentation (just as @param was used). IMO, this improves legibility. This is not required for approval, though.

  4. Install from GitHub did not install all package documentation (missing several of the get* variables). Perhaps the documentation hasn't been fully updated in the master branch?

  5. The tests seem to fail if the skip("Heavy web usage") line is commented,

Exited with status 15.

I thought this had worked earlier but I may have been mistaken. If I leave it uncommented as it was then the tests pass.

  1. goodpractice::gp() output:

── GP hydroscoper ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

It is good practice to

✖ write unit tests for all functions, and all package code in general. 73% of code lines are covered by test cases.

R/enhydris.R:19:NA
R/enhydris.R:20:NA
R/enhydris.R:26:NA
R/enhydris.R:34:NA
R/enhydris.R:42:NA
... and 47 more lines

✖ fix this R CMD check NOTE: Note: found 3031 marked UTF-8 strings

commented

Many thanks, @timtrice, for your time and effort! I will start working on these issues as soon as possible.

commented

Thank you @timtrice for your review! 😸 And thanks @kvantas for being so reactive! Feel free to wait for the second review if that's easier for you. 😺

CONTRIBUTING.md and CONDUCT.md are two separate files that should both exist.

@kvantas do you plan a JOSS submission? If so, could you add a paper.md conform to JOSS guidelines? Thanks.

commented

Oops actually sorry we do not recommend any CONTRIBUTING.md yet!

commented

If you solve bugs @kvantas please update this thread so that @sharlagelfand might know which package version to use for her review.

commented

That's OK, I can add CONTRIBUTING.md.

@maelle, I already have a paper.md in inst/paper. I think that @timtrice used an older version of my package and not 0.2.1, as I write in Summary.

Anyway, I will follow @timtrice comments and update this thread about the package version.

Thanks again, and sorry if I am missing something obvious.

commented

Thanks and no worries!

commented

Hello all, this is a list of the updates/changes I have made in response to @timtrice 's review.

1., 2. I replaced that vignette with a new one: stations_with_data.Rmd that uses the package's data-sets and does not make heavy web usage as the previous one.
3. I added CONTRIBUTING.md
4. I moved paper.md and paper.bib from inst/paper to the root directory .
5. I added @title, @description, @details and @section tags in function documentation.
6. I used @rdname to document multiple functions (almost all the get_... functions).
7. I tide up the internal, API-related functions, wrote tests again utilizingtestthat::skip_on_cran() and a custom function, skip_if_not_online(); there is no need to comment anything in tests now.
8. Using Sys.setenv(NOT_CRAN="true") and goodpractice::gp() :

♥ Yee-haw! Classy package! Keep up the awe-inspiring work!

Sys.setenv(NOT_CRAN="true") and covr::package_coverage() returns:

hydroscoper Coverage: 100.00%

Sys.setenv(NOT_CRAN="false") and devtools::check() returns:

 0 errors ✔ | 0 warnings ✔ | 0 notes ✔

@timtrice, thanks for your review, it really improved my package's structure and testing. Please let me know if I missed something.

@maelle and @sharlagelfand please use the package version 0.2.3.

commented

Thanks for your work @kvantas !

commented

@sharlagelfand friendly reminder that your review is due on 2018-02-21 😉

commented

thanks for the reminder @maelle! working on it and hoping to wrap up this weekend

commented

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 5

Review Comments

I really enjoyed reviewing this package and especially from an end-user standpoint -- I hope you don't mind the specificness of some of these comments with that in mind! :)

Tests

library(covr)
Sys.setenv(NOT_CRAN="true")
covr::package_coverage()

hydroscoper Coverage: 100.00%
R/defunct.R: 100.00%
R/enhydris_api.R: 100.00%
R/get_data.R: 100.00%
R/get_tables.R: 100.00%
R/hydro_coords.R: 100.00%
R/hydro_translate.R: 100.00%
R/translit.R: 100.00%
R/utils.R: 100.00%

library(goodpractice)
goodpractice::gp()

It is good practice to

✖ fix this R CMD check NOTE: Note: found 3031 marked UTF-8 strings
✖ fix this R CMD check WARNING: LaTeX errors when creating PDF version. This typically indicates
Rd problems. LaTeX errors found: ! LaTeX Error: File `inconsolata.sty' not found. Type X to quit or
<RETURN> to proceed, or enter new name. (Default extension: sty) ! Emergency stop. <read *> l.276 ^^M !
==> Fatal error occurred, no output PDF file produced!

This second one just might be my system -- I don't think I have LaTeX on this computer.

devtools::check()
R CMD check results
0 errors | 0 warnings | 0 notes

devtools::test()
✔ | OK F W S | Context
✔ |  1       | defunct related tests
✔ |  1       | Test enhydris_api helper functions
✔ |  2       | enhydris_url returns expected addresses
✔ |  3     1 | Test that expected tables exist in sub-domains' databases [11.6 s]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
test_enhydris.R:62: skip: deh returns expected tables
deh.hydroscope.gr is not online
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
✔ |  4       | Test enhydris_get and enhydris_list functions⠋ |  1       | Test enhydris_get and enhydris_list functions [21.9 s]
✔ |  1       | Test enhydris_list function [2.5 s]
✔ |  2       | get_data function tests
✔ | 13       | get_tables family function tests
✔ |  2       | hydro_coords tests [0.1 s]
✔ |  7       | Translitetation and translation functions
⠋ |  1       | utils testsping: cannot resolve xxx.hydroscope.gr: Unknown host
✔ |  2       | utils tests

══ Results ════════════════════════════════
Duration: 36.3 s

OK:       38
Failed:   0
Warnings: 0
Skipped:  1

You are a coding rockstar!

Looks like the skipped test is expected, or it is expected to return an error, at least -- do you mind clarifying?

Examples run unsuccessfully

The example for get_instruments_type() fails. This is because it is not exported properly -- in R/get_tables.R I can see it has #' @export get_owners above it instead of #' @export get_instruments_type -- I assume once the correct function is exported, it will run fine (since the example for get_database runs just fine!).

README

The README is great. It provides good background on the Hydroscope project itself, what is included in it, and limitations (i.e., that the files are in Greek). I liked the list of what hydroscoper does with data from Hydroscope, and especially how it addresses the limitations to make the data more usable.

Something that did confuse me is the timeseries data set and reference to it. Perhaps it's that I'm missing the context, but I think further explanation of what this data set is would be helpful in both the README, the data set's documentation, and the vignettes. My impression is that it is a lookup table of all of the available measurements for a given station in a given domain, with units of measurement and the time that those measurements are for (hence the name timeseries) -- I think highlighting more concretely what exactly it is a time series of would be useful.

Vignettes

I think the vignette(s?) could use a gentler introduction to Hydroscope and the hydroscoper package, similar to the README. I'm imagining the case where someone finds this package on CRAN, not on GitHub, and needs more background into what the package has (functions, data sets) than is included in the current vignettes.

I'm not entirely clear if the hydroscope_data vignette is in the wrong place (data-raw/ instead of vignettes/), or if it is meant to be used to create the timeseries data set (hence its location) and is not actually a vignette at all! I think the latter, since you created the stations_with_data.Rmd after @timtrice's review, but just wanted to double check :)

Function Documentation

  • get_data
    • The documentation references an argument timeID when it is actually time_id
    • There is inconsistent usage of tibble/data frame/dataframe throughout
    • It says that it will return a data frame if the subdomain is "kyy" or "ypaat" and the time argument is not NULL, and an error otherwise; but it will also throw an error if the time_id is not NULL and it doesn't correspond to a timeseries in the timeseries lookup -- I wonder if it would be useful to be clearer that the subdomain and time_id combination must exist in timeseries (and therefore must exist in Hydroscope). It might sound silly, but the time_id not being NULL is not enough on its own.
    • The actual code for this function has a comment saying it is checking that stationID is not null, though it is actually checking that time_id is not null.

Miscellanious thoughts

  • The timeseries data set has a column timeser_id, which is then used as an argument in get_data() -- however, the argument in this function is named time_id. I think it would be clearer to either rename the variable name in timeseries to time_id, or to change the argument in get_data() to timeser_id, so that they are consistent.
  • The list that get_database() has an element called units, though the function that retrieves it is called get_units_of_measurement() -- all of the other list elements match the name of their corresponding functions, so I think it would be useful if this one did as well.
  • The greece_borders data set is a data.frame, not a tbl_df like the other two data sets (the documentation indicates that it is a tibble as well).
  • IMO the get_data() function should return columns date, value, and comment, rather than dates, values, and comments -- a single row contains the measurement (value) on a given date, with a comment. I don't think (?) it's customary for variable names to be pluralized.

I have also submitted a PR with a few fixes on documentation/typos -- nothing major, just when I saw things that could quickly be fixed and didn't need to be brought up here!

commented

Many thanks for your thorough review @sharlagelfand! 👌

commented

@sharlagelfand, many thanks for your review, your time spent and your good words! Thanks a lot, also, for your contribution on the package with the PR. I 'll start working on your comments as soon as possible.

commented

Hello again! I have made the suggested changes:

response to @sharlagelfand

Tests

  • The only file with UTF8 encoding is README.md, and it is created automatically. I 'll need some help on how to change it to ASCII.
  • On my laptop, for some strange reason, running goodpractice::gp() returns no errors and I don't get a warning about LaTeX or encoding.
  • The skipped test is expected because subdomain deh.hydroscope.gr is currently down. Generally, if a server is down the corresponding test is skipped.

Examples run unsuccessfully

I exported properly get_instruments_type() in ropensci/hydroscoper@af0297e

README

I added further explanation about timeseries in README, data set's documentation, and the vignettes in ropensci/hydroscoper@5636c7c

Vignettes

  • I added a gentler introduction to Hydroscope and the hydroscoper package in ropensci/hydroscoper@d7e9a3f
  • Actually, hydroscope_data used to be a vignette, but I removed it due to its heavy web usage.

Function Documentation

  • In function: get_data : (1) I replaced timeID with time_id, (2) rewrote @return text, (3) replaced stationID with time_id at the comment and (4) used the term tibble instead of data-frame in ropensci/hydroscoper@445f0cc
  • I used throughout documentation only the term tibble in ropensci/hydroscoper@20ee57c

other recommendations

commented

Thanks @kvantas!

@timtrice and @sharlagelfand could you please have a look and say whether you're satisfied with the changes made?

commented

Hoping to take a look at these changes in the next couple of days! Thanks @kvantas @maelle :)

commented

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:

Review Comments

  1. Vignettes look much better! Good job.

  2. goodpractice::gp() results are great. 78% code coverage. Very good!

  3. All other issues or comments appear to have been addressed. Again, I'm ignoring the JOSS section as I feel this is beyond my knowledge. @maelle if you want to provide some input or guidance, I'd take it.

Good job, @kvantas!

commented

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all exported functions in R help
  • Examples for all exported functions in R Help that run successfully locally
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).
For packages co-submitting to JOSS

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Unit tests cover essential functions of the package
    and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 6

Thank you for all the changes made @kvantas! I appreciate that you itemized them and linked to the relevant commits -- made for super easy follow up.

I think the additional vignette is great (especially for discovery outside GitHub) and the explanations of the stations and timeseries data sets are as well -- really helps to clarify what is contained in the package.

All of the comments I had have been addressed, so this package is good to go by me! I also don't know much about JOSS but from poking around, seemed like a good fit. Happy to default to @maelle on this!

commented

Approved! 👏

Thanks a lot @kvantas @sharlagelfand @timtrice for your work! 👏 👏 👏 Note that normally reviewers update the first checklist, but it's fine to have copied it, don't change it now! 😸

I have four suggestions:

  • improving readability/browsability of the README via splitting it/adding a table of contents or even making it minimal and linking to the vignettes (instead of reproducing one of them).

  • Add the pkgdown link to DESCRIPTION, see http://enpiar.com/2017/11/21/getting-down-with-pkgdown/ "if you already have a URL there (say, to your package’s GitHub repository), you can add a second URL to your pkgdown site, separated by a comma"

  • If you wish you can add reviewers to DESCRIPTION with the "rev" role. If you do that ask them first though. 😉

  • In the pkgdown website you might want to make the grouping of functions in reference more useful. See https://github.com/dirkschumacher/ompr for an example

Now here is the list of things you have to do before I close this issue 😉

  • [] Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.

  • [] Fix any links in badges for CI and coverage to point to the ropensci URL

  • [] Activate Zenodo watching the repo

  • [] Tag and create a release so as to create a Zenodo version and DOI

  • [] Submit to JOSS using the Zenodo DOI. We will tag it for expedited review.

Welcome aboard! We'd also love a blog post about your package, either a short-form intro to it (https://ropensci.org/tech-notes/) or long-form post with more narrative about its development. ((https://ropensci.org/blog/). If you are, @stefaniebutland will be in touch about content and timing.

commented

Thanks a lot @maelle, @timtrice and @sharlagelfan. @maelle, on the following days I will apply your suggestions and do what is needed to transfer the repo. Also, I will write a blog post about the package.

@timtrice do you mind if I add you as a reviewer?
@sharlagelfand is it ok to add you as a contributor/reviewer?

commented

Not at all; thank you

commented

I will write a blog post about the package
Excellent!
Here are some technical and editorial guidelines: https://github.com/ropensci/roweb2#contributing-a-blog-post

We ask that you submit your draft post via pull request a week before the planned publication date so we can give you some feedback. I have a slot open on Tues April 3rd for a draft to be submitted March 27. How does that sound? If you submit earlier we can publish earlier if another is postponed

commented

That would be lovely, thanks @kvantas!

commented

@stefaniebutland, I think that the date is OK.

commented

@kvantas could you please soon transfer your repo? 🙏

commented

@maelle, sorry for the delay, some work kept me back. I followed all your suggestions in
ropensci/hydroscoper#11,
ropensci/hydroscoper#12,
ropensci/hydroscoper#13,
ropensci/hydroscoper#14

But I have some problems:

a) ropensci/hydroscoper in travis is locked
b) I cannot edit the description in https://github.com/ropensci/hydroscoper
c) I cannot find a link in Zenodo

commented

a) yeah you do not have access, what do you need to do? I'll be traveling soon so please ping one of the editors in the # onboarding Slack channel
b) c) I made you an admin of the repo now, which I couldn't do before transfer 😉

commented

d) Appveyor now activated

commented

@maelle, a) I thought that the repo in travis was off 🐱

Thank you very much again 🎉

commented

I submitted the 📦 to JOSS, the last thing on the list 😸

Everything is ok 🚀 🚀 ⚡️

commented

Fantastic, congrats! 👏 I'm looking forward to reading your blog post!

commented

@kvantas Are you still ok with submitting your draft blog post by Tues Mar 27?

commented

@stefaniebutland, I have some small projects to finish, but I think I will be ready for the draft post. 📆