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/epinowcast")) 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).
- In general we aim to use
data.tableto manipulate data. However, if this is a barrier to contributing please use tools you are familiar with and raise this in your pull request. The reviewer will then work with you to refactor your contribution or if appropriate add the dependencies you require.
- 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 our package style or where not specified 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.
- Note that when run locally our testing suite only tests R level code. When run in the cloud (i.e when a PR is opened) we also run additional tests on the stan level code. When making stan level changes contributors may want to run these tests manually prior to opening a PR.