Development is a community effort, and we welcome participation.
Please note that this package is released with a Contributor Code of Conduct.
At https://github.com/ropensci/targets/discussions, you can post general questions, brainstorm ideas, and ask for help.
https://github.com/ropensci/targets/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
remotes::install_github("ropensci/targets")) 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.
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 the
- For new features or functionality, add tests in
tests. Tests that can be automated should go in
tests/testthat/. Tests that cannot be automated should go in
tests/interactive/. For features affecting performance, it is good practice to add profiling studies to
- 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
- Describe your contribution in the project’s
NEWS.mdfile. 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
[email protected]field of the