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 lesson, 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).
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.