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.
- If it's a question: start with community.rstudio.com. There are more people there to answer questions.
- If it's a bug: you're in the right place, file an issue.
- If it's a feature request: you're in the right place, file an issue.
- If you're not sure: let the community help you figure it out! If your problem is a bug or a feature request, you can easily return here and report it. You can use our other inquiry issue template to get our feedback.
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.
Once you are done, make sure that all changed .Rmd documents knit without error.
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.