This explains how to propose a change to driftR via a pull request using Git and GitHub.
Before you do a pull request, you should always file an issue and make sure someone from the driftR team agrees that it’s a problem, and is happy with your basic proposal for fixing it. If you’ve found a bug, first create a minimal reprex.
The first thing you’ll need to do is to fork the driftR GitHub repo, and then clone it locally. We recommend that you create a branch for each PR.
Before changing anything, make sure the package still passes R CMD check locally for you. When in doubt, compare your R CMD check results with current results for stlData on Travis (checks on Linux and/or MacOS) and, if applicable, AppVeyor (checks on Windows). You’ll do this again before you finalize your pull request, but this baseline will make it easier to pinpoint any problems introduced by your changes.
Match the existing code style. This means you should follow the tidyverse style guide. Use the styler package to apply the style guide automatically.
Be careful to only make style changes to the code you are contributing. If you find that there is a lot of code that doesn’t meet the style guide, it would be better to file an issue or a separate PR to fix that first.
We use roxygen2, specifically with the Markdown syntax, to create NAMESPACE and all .Rd files. All edits to documentation should be done in roxygen comments above the associated function or object. Then, run devtools::document() to rebuild the NAMESPACE and .Rd files.
See the RoxygenNote in DESCRIPTION for the version of roxygen2 being used.
We use testthat. Contributions with test cases are easier to accept. If you are not sure what parts of your code are covered by tests, run the following to get a local coverage report of the package so you can see exactly what lines are not covered in the project.
For user-facing changes, add a bullet to NEWS.md that concisely describes the change. Small tweaks to the documentation do not need a bullet. The format should include your GitHub username, and links to relevant issue(s)/PR(s), as seen below.
Before submitting your changes, make sure that the package either still passes R CMD check, or that the warnings and/or notes have not changed as a result of your edits.
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).
NEWS.md is a good source of examples for both content and styling.This document is adopted from @jennybc’s Contribution document for the usethis package.
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.