admiral
admiral copied to clipboard
Closes #2388 numeric country decodes
Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the main
branch until you have checked off each task.
- [x] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
- [x] Code is formatted according to the tidyverse style guide. Run
styler::style_file()
to style R and Rmd files - [x] Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
- [x] If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
- [x] Review the Cheat Sheet. Make any required updates to it by editing the file
inst/cheatsheet/admiral_cheatsheet.pptx
and re-upload a PDF version of it to the same folder. - [x] Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
- [x] Run
devtools::document()
so all.Rd
files in theman
folder and theNAMESPACE
file in the project root are updated appropriately - [x] Address any updates needed for vignettes and/or templates
- [x] Update
NEWS.md
under the header# admiral (development version)
if the changes pertain to a user-facing function (i.e. it has an@export
tag) or documentation aimed at users (rather than developers). A Developer Notes section is available inNEWS.md
for tracking developer-facing issues. - [x] Build admiral site
pkgdown::build_site()
and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page. - [x] Address or fix all lintr warnings and errors -
lintr::lint_package()
- [x] Run
R CMD check
locally and address all errors and warnings -devtools::check()
- [x] Link the issue in the Development Section on the right hand side.
- [x] Address all merge conflicts and resolve appropriately
- [x] Pat yourself on the back for a job well done! Much love to your accomplishment!
Package | Line Rate | Health |
---|---|---|
admiral | 97% | ✔ |
Summary | 97% (4685 / 4813) | ✔ |
I think we have 2 other possible solutions for storing the country codes:
- Have a function called
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie.dataset_add = get_country_codes()
. - We store the dataset in
data
folder with r script that creates it stored in a sub-folder ofinst
(data.R would need updated also).
I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
I think we have 2 other possible solutions for storing the country codes:
- Have a function called
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie.dataset_add = get_country_codes()
.- We store the dataset in
data
folder with r script that creates it stored in a sub-folder ofinst
(data.R would need updated also).I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
Usually, datasets are stored in data
and the scripts which create them should be stored in data-raw
. Unfortunately, we are not following this convention. I would discuss it at the next meeting.
I think we have 2 other possible solutions for storing the country codes:
- Have a function called
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie.dataset_add = get_country_codes()
.- We store the dataset in
data
folder with r script that creates it stored in a sub-folder ofinst
(data.R would need updated also).I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
Thanks @millerg23 and @bundfussr, I noticed dose_freq_lookup
in create_single_dose_dataset()
creates a tibble in this way. But I agree they should be consistent.