How to Contribute

Thanks for contributing. Following Hadley Wickham recommendations for most things will make it easier to accept contributions to the package, although we try hard not to introduce new dependencies, including tidyverse packages. His free online books on R coding and packaging are essential resources. This document contains some specific 'icd' things to help get you started.

Fork the icd project on github, and clone it to your local machine. Develop locally and then push your commits to your fork on github. The project uses continuous integration, so when your work is pushed you'll get automatic alert if it passed the builds or needs adjustment. Both Travis and Appveyor are used because they able to do different checks. One may pass when the other fails.

Once CI tests are successful a pull request can be made for review and discussion before merging into the master branch. CRAN releases are every few months, so initially your code will only be available to people using the github version of 'icd'. If it is an important fix, changes will be pushed to CRAN as soon as they will allow.

Before pushing commits or submitting pull requests.

Use the work flow recommended by Hadley Wickham. http://r-pkgs.had.co.nz/check.html This package is heavily influenced by his recommendations. Before submitting a pull request, the package should pass full CRAN check, all tests and lints, and include new tests which cover any new code. New code should have new tests in tests/testthat.

Use of External Packages

Please avoid using additional external packages, as these often pull in a storm of new dependencies (and thus increase scope for bugs. See http://www.tinyverse.org/). Usually a fast enough and clean solution can be found using base R, or the packages already imported or suggested. I'm pleased that many people have contributed code, but if each person depends on a particular favourite package, the dependency tree will soon balloon.

Unit Tests

Unit-tests will have to pass in Travis & Appveyor for the merge/pull requests to be successful. Please push unit tests with working code. If you write tests before code, run tests locally until they pass, then create pull request. All new code will need unit tests. If you find a bug, please make a reproducible example in the form of a 'testthat' test.

Style

See existing code. styler::style_pkg() should be run on new code, and is run routinely on the whole code-base. C/C++ code is not covered. clang-format is used intermittently to tidy up the C/C++ code.