Skip to contents

Contributing

Development is a community effort, and we welcome participation. For more details on other forms of contribution please see our community contribution page.

Community

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.

Code of Conduct

By participating in this project, you agree to abide by the code of conduct.

Discussions

At https://community.epinowcast.org, you can post general questions, brainstorm ideas, and ask for help.

Issues

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 hashprng (i.e. remotes::install_github("epinowcast/hashprng")) 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 other contributors and authors 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

Contributions

External code contributions are extremely helpful and appreciated. Here are the recommended steps.

  1. 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.
  2. Fork the repository.
  3. Follow the GitHub flow to create a new branch, add commits, and open a pull request.
  4. Discuss your code with the reviewer in the pull request thread.
  5. 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 style guide. Automatic tidyverse styling can be achieved by running styler::style_pkg() from styler (which rewrites the files) and lintr::lint_package() from lintr (which provides a list of complaints for you to resolve). Note: styler::style_pkg() does not examine roxygen content i.e. @examples so 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 devtools::check() and goodpractice::gp()
  • Describe your contribution in the project’s NEWS.md file. 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@R field of the DESCRIPTION file. 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.