fingertipsR

[sebastian-fox]

Summary

• What does this package do? (explain in 50 words or less):
  The package provides an interface to the API for the Fingertips website, a site developed by Public Health England. It enables users to import data on over 2,000 indicators of public health in England at different levels of geography.

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

Package: fingertipsR
Type: Package
Version: 0.1.3.9000
Title: Fingertips Data for Public Health
Description: Fingertips (<http://fingertips.phe.org.uk/>) contains data for many indicators of public health in England. The underlying data is now more easily accessible by making use of the API.
Depends: R (>= 2.10)
Authors@R: c(person("Sebastian", "Fox", , "sebastian.fox@phe.gov.uk", c("aut", "cre")),
    person("Julian", "Flowers", , "julian.flowers@phe.gov.uk", c("aut","ctb")))
URL: https://fingertips.phe.org.uk
BugReports: https://github.com/PublicHealthEngland/fingertipsR/issues
Imports:
    dplyr,
    jsonlite,
    data.table,
    httr,
    purrr,
    DT,
    miniUI,
    shiny,
    shinycssloaders,
    readr
Suggests:
    knitr,
    rmarkdown,
    testthat,
    ggplot2,
    pander,
    curl
VignetteBuilder: knitr
License: GPL-3
Encoding: UTF-8
LazyData: true
RoxygenNote: 6.0.1

• URL for the package (the development repository, not a stylized html page):

https://github.com/PublicHealthEngland/fingertipsR

• 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 it provides users with functions to import data for over 2,000 indicators of public health in England from the Fingertips website.

•   Who is the target audience and what are scientific applications of this package?  

The target audience is anyone with an interest in public health. This includes researchers, public and private sector workers and the general public. The website gets almost one million hits in a year. The majority of users are in the public sector who need to make decisions that affect the public's health. This website helps inform those decisions. Increasingly, the website is being accessed by academic institutions. The fingertipsR package is already on CRAN and it is being discussed in some institutions as a future resource for teaching materials.

• 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

•   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.

NA

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, Coeveralls 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

• [Already on CRAN] Do you intend for this package to go on CRAN?
• [No] 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:
  • (Do not submit your package separately to JOSS)
• [No] 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:

• 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:

[karthik]

👋 sebastian-fox
Thank you for your submission to rOpenSci's onboarding. I've tagged your submission as a presubmission while I do some preliminary checks before I assign an editor.

[noamross]

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

Thank you for your submission, @sebastian-fox ! I see you are running the package on Travis already, but we do require a CI badge in your README as well as a continuous code coverage service (generally codecov or coveralls) and a badge from that, as well, so we can see package status at a glance. I'm seeking reviewers and will assign them once you've made this update.

Here is output from goodpractice::gp(). I see nothing sufficient to hold up assigning reviewers, but 58% test coverage is a bit on the low side, and the rest should be handled by the end of review. Things like line length and whole-package imports are up to the judgement of reviewers and this serves a reference for them and you.

── GP fingertipsR ────────────────────────────────────

It is good practice to

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

    R/area_types.R:36:NA
    R/area_types.R:93:NA
    R/area_types.R:94:NA
    R/area_types.R:95:NA
    R/area_types.R:96:NA
    ... and 181 more lines

  ✖ use '<-' for assignment instead of '='. '<-' is the standard, and R users and
    developers are used it and it is easier to read your code for them if you use '<-'.

    R/select_indicators.R:48:33

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor
    windows that are about 80 characters wide. Try make your lines shorter than 80 characters

    R/area_types.R:36:1
    R/area_types.R:61:1
    R/area_types.R:66:1
    R/area_types.R:69:1
    R/deprivation_decile.R:38:1
    ... and 103 more lines

  ✖ avoid sapply(), it is not type safe. It might return a vector, or a list, depending on
    the input data. Consider using vapply() instead.

    R/fingertips_data.R:187:33
    R/fingertips_data.R:188:48
    tests/testthat/test-deprivation.R:21:22
    tests/testthat/test-deprivation.R:22:22
    tests/testthat/test-deprivation.R:23:22
    ... and 1 more lines

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...), 1:NROW(...) and 1:NCOL(...)
    expressions. They are error prone and result 1:0 if the expression on the right hand side is
    zero. Use seq_len() or seq_along() instead.

    R/retrieve_data.R:10:19

  ✖ not import packages as a whole, as this can cause name clashes between the imported
    packages. Instead, import only the specific functions you need.
──────────────────────────────────────────────

---

Reviewers: @carlganz, @nacnudus
Due date: 2018-01-15

[sebastian-fox]

Thanks for taking a look at this. I have added the badges as requested. I have also improved the coverage of the package.

I've also updated some of the code based on the goodpractice feedback

[noamross]

Reviewers are @carlganz and @nacnudus. In light of the end-of-year holidays, due date is 2018-01-15.