Development is a community effort, and we welcome participation. For more details on other forms of contribution please see our community contribution page.
We hold a monthly community call where we discuss package development, research questions, and developments in the literature. We also run a slack community where additional development discussion takes places. We welcome new comers, please contact a package author for an invite.
By participating in this project, you agree to abide by the code of conduct.
At https://community.epinowcast.org, you can post general questions, brainstorm ideas, and ask for help.
https://github.com/epinowcast/epinowcast/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, 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("epinowcast/hashprng")) and verify that the issue still persists.
Describe your issue in prose as clearly and concisely as possible.
- 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
External code contributions are extremely helpful and appreciated. Here are the recommended steps.
- Prior to contribution, please propose your idea in a new issue thread so you and the reviewer can define the intent and scope of the 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 reviewer in the pull request thread.
- If everything looks good, the reviewer 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 to the
tidyverse styleguide. Automatic
tidyversestyling can be achieved by running
styler(which rewrites the files) and
lintr(which provides a list of complaints for you to resolve). Note:
styler::style_pkg()does not examine roxygen content i.e.
@examplesso you will need to check that manually.
- 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 relevant GitHub issue numbers and your GitHub name as done in existing news entries.
- If you feel your contribution is substantial enough for author or contributor status, please add yourself to the
Authors@Rfield of the
DESCRIPTIONfile. In general, we consider any contribution sufficient for contributor status and several minor or a single major contributions sufficient for author status. If planning on writing a paper or similar about your package extension please note this in your contribution and feel free to suggest how you would like this to be managed.