Thanks for using this package. Before filing an issue or opening a pull request, there are a few places to explore and pieces to put together to make the process as smooth as possible.
Start by making a minimal reproducible example (reprex) using the reprex package. If you haven’t heard of or used reprex before, you’re in for a treat! Seriously, reprex will make all of your R-question-asking endeavors easier (which is a pretty insane ROI for the five to ten minutes it’ll take you to learn what it’s all about). For additional reprex pointers, check out the Get help! section of the tidyverse site.
Armed with your reprex, the next step is to figure out where to ask.
Before opening a new issue, be sure to search issues and pull requests to make sure the bug or typo hasn’t been reported and/or already fixed. Similarly, search to make sure someone has not already made a suggestion. If there is a suggestion and you want to express support for it, please comment in the existing issue.
By default, the search will be pre-populated with is:issue is:open. You can edit the qualifiers (e.g. is:pr, is:closed) as needed. For example, you’d simply remove is:open to search all issues in the repo, open or closed.
When you go to open an issue, you are encouraged to select from one of the three templates: bug reports, feature requests, or other inquiries. These will help you craft an issue that is as helpful and clear as possible!
If you’ve found a way to contribute, please follow the PR process described here to fork, edit, and push your proposed changes. We recommend opening an issue to gauge our interest before spending time working on a PR!
The first thing you’ll need to do is to fork this package, and then clone it locally. We recommend that you create a branch for each PR.
Match the existing code or documentation style. Be careful to only make style changes to the code you are contributing.
Make sure to update the help files if your changes impact any of those documents. If you add a new package dependency, please also update the DESCRIPTION file so that the dependency is part of our continuous integration testing.
When you’ve made your changes, write a clear commit message describing what you’ve done. If you’ve fixed or closed an issue, make sure to include keywords (e.g. fixes #101) at the end of your commit message (not in its title) to automatically close the issue when the PR is merged.
Once you’ve pushed your commit(s) to a branch in your fork, you’re ready to make the pull request. Pull requests should have descriptive titles to remind reviewers/maintainers what the PR is about. You can easily view what exact changes you are proposing using either the Git diff view in RStudio, or the branch comparison view you’ll be taken to when you go to create a new PR. If the PR is related to an issue, provide the issue number and slug in the description using auto-linking syntax (e.g. #15).
When CDC/ATSDR publishes a new Social Vulnerability Index (SVI) database vintage (the schedule has historically been every two years), use this checklist before extending deprivateR to support it. It generalizes the process that surfaced and fixed the svi20/svi20s SES percentile inversion (#88):
deprivateR currently implements for the closest existing svi<NN> style, in R/sysdata.rda’s request_vars. Note every added, removed, or redefined variable.EPL_PCI is the only currently documented negative-correlation exception (see tests/testthat/test_dep_process_svi.R, T4) — a new vintage could introduce others, or could change an existing variable’s direction the way the 2020 vintage’s EP_HBURD/EP_UNINSUR were mishandled in #88.svi<NN> style is required, or whether the new vintage is backward-compatible with an existing style (the way svi20s exists specifically because the 2020 single-parent-household variable change is not backward compatible with svi20).tests/testthat/fixtures/ (Missouri-scoped, following the precedent set by cdc_svi_2020_missouri_county.csv / cdc_svi_2022_missouri_county.csv), and add it to inst/validate-data/scheduled_validation.R’s vintages list so the recurring drift-detection workflow (.github/workflows/validation.yaml) covers it going forward.scheduled_validation.R for the empirical magnitude of this effect.R/dep_get_index.R roxygen, README.Rmd, vignettes/deprivateR.Rmd) with the new style’s supported year range, and add a boundary test asserting the accepted/rejected year range so documentation and enforcement cannot drift apart (see #89).Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
These contributing guidelines are modified from those used by Jenny Bryan.