Contributing
Source:CONTRIBUTING.md
Development is a community effort, and we welcome participation.
Code of Conduct
Please note that the gittargets
project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms.
Discussions
At https://github.com/ropensci/gittargets/discussions, you can post general questions, brainstorm ideas, and ask for help.
Issues
https://github.com/ropensci/gittargets/issues is for bug reports, performance issues, maintenance tasks, and feature requests. When you post, please abide by the following guidelines.
- Before posting a new issue or discussion topic, please take a moment to search for existing similar threads in order to avoid duplication.
- For bug reports: if you can, please install the latest GitHub version of
gittargets
(i.e.remotes::install_github("ropensci/gittargets")
) and verify that the issue still persists. - Describe your issue in prose as clearly and concisely as possible.
- For any problem you identify, post a minimal reproducible example like this one so the maintainer can troubleshoot. A reproducible example is:
- Runnable: post enough R code and data so any onlooker can create the error on their own computer.
- Minimal: reduce runtime wherever possible and remove complicated details that are irrelevant to the issue at hand.
- Readable: format your code according to the tidyverse style guide.
Development
External code contributions are extremely helpful in the right circumstances. Here are the recommended steps.
- Prior to contribution, please propose your idea in a discussion topic or issue thread so you and the maintainer can define the intent and scope of your work.
- Fork the repository.
- Follow the GitHub flow to create a new branch, add commits, and open a pull request.
- Discuss your code with the maintainer in the pull request thread.
- If everything looks good, the maintainer will merge your code into the project.
Please also follow these additional guidelines.
- Respect the architecture and reasoning of the package. Depending on the scope of your work, you may want to read the design documents (package vignettes).
- If possible, keep contributions small enough to easily review manually. It is okay to split up your work into multiple pull requests.
- Format your code according to the tidyverse style guide and check your formatting with the
lint_package()
function from thelintr
package. - For new features or functionality, add tests in
tests
. Tests that can be automated should go intests/testthat/
. Tests that cannot be automated should go intests/interactive/
. For features affecting performance, it is good practice to add profiling studies totests/performance/
. - Check code coverage with
covr::package_coverage()
. Automated tests should cover all the new or changed functionality in your pull request. - Run overall package checks with
devtools::check()
andgoodpractice::gp()
- Describe your contribution in the project’s
NEWS.md
file. Be sure to mention relevent GitHub issue numbers and your GitHub name as done in existing news entries. - If you feel contribution is substantial enough for official author or contributor status, please add yourself to the
Authors@R
field of theDESCRIPTION
file.