Development is a community effort, and we welcome participation.
Code of Conduct
By participating in this project, you agree to abide by the code of conduct.
Anyone can submit an issue to https://github.com/EliLillyCo/rfacts/issues or comment on an existing thread. Common reasons are to
- Suggest features.
- Report bugs.
- Request help with difficult use cases.
- Ask questions.
Please abide by the following guidelines.
- All information you post is publicly visible. No confidential or proprietary information should be posted on the development page or become part of the package itself.
- Before posting a new issue, please take a moment to search for existing similar issues in order to avoid duplication.
- For bug reports: if you can, please install the latest GitHub version of
remotes::install_github("EliLillyCo/rfacts")) and verify that the issue still persists.
- Describe your issue in prose as clearly and concisely as possible. The following three-paragraph format is preferred.
- For any problem you identify, post a minimal reproducible example 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 new 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.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 the