-
Notifications
You must be signed in to change notification settings - Fork 61
How to Contribute
Thanks for contributing. Following Hadley Wickham recommendations for most things will make it easier to accept contributions to the package. 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, 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 Wercker and Travis 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'.
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.
Please avoid using additional external packages, as these often pull in a storm of new dependencies (and thus increase scope for bugs). Usually a fast enough and clean solution can be found using base R, or the packages already included. 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 will have to pass in Travis & Wercker 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.
Linting seems a pain, but consistency in code from multiple contributors makes the package easier to change in the future, and catches some bugs. See the Jim Hester's 'lintr' package documentation. It is best to use Rstudio hints to do this as you go along, but this won't catch everything.
A first stab at delinting can be done via RStudio - 'Code' -> 'Reformat 'Code' (ctrl-shift-A) Then the package devtools::lint (or the package lintr) can be used. This is the same lint check used in Travis / Wercker.
The package formatR is handy tool, it can format a directory, whatever is in your clipboard or via its shiny app UI. It can replace = with <-, although it can have trouble with magrittr.