NA

Guidelines for Contributing

Thanks for checking out our project! If you haven’t already, please check out the readme for general info about this project.

Contributor Code of Conduct

All contributors will be expected to follow our code of conduct.

For the General Public

If you’re not a collaborator on this project, we ask that you use one of the following two methods for contributing:

1. Create an issue – if you spot any typos, bugs, or have general suggestions, etc. You can also use this to participate in ongoing discussions. For more info, please check out this Github guide.

2. Fork and create a pull request – if you have suggested bugfixes or changes. For more info, please check out this Github guide. We ask that you follow our guidelines below on documentation and testing.

Documentation

If you are only contributing code to this project, and don’t intend to run anything, you generally don’t need any additional packages, since the documentation will be written as comments in the R scripts. If you are also planning to run the analysis, please see the instructions in the README for more details.

In most cases, you’ll be creating a new function and then documenting it. You can check the existing functions for examples, but here’s a basic template:

#' @title {this is the heading for the help file}
#'
#' @description {A description of the function}
#'
#' @param {name of a function argument} {what the argument does}
#' @return {what is returned from the function}
#' @examples
#' {R code that is an example use of the function}
#' @export
#'
newfunc <- function() ...

Note that you can also include links to other functions, math formatting, and more. For more details, see the chapter on documentation in Hadley Wickham’s book for R packages.

Testing

If you are adding new functionality, please include automated tests to verify that some of the basic functionality is correct.

Automated testing uses R scripts, that live in the tests/testthat/ subfolder for the package. If you are adding a new file, please name it as test-{concept}.R.

As a general rule, you don’t need to test all possible inputs and outputs for a function, but you should test some important aspects:

• outputs are the correct format (including dimensions and components)
• sample input produces the correct sample output

You can see the existing tests as examples of how to organize your tests, but note that there are several different kinds of expect_ functions that test for different things. For more details, see the chapter on testing in Hadley Wickham’s book for R packages.

Updating the Package code

The suggested workflow is:

1. Write code, documentation, and tests.

• To add dependencies on external packages, use usethis::use_package("package name"). This will modify the documentation on this package accordingly. If you are adding a dependency to a package that is NOT on CRAN, use usethis::use_dev_package("package name") instead.

1. Run devtools::document() to generate the documentation files and update the NAMESPACE file.
2. Run devtools::install() to install the new version of the package.
3. Run devtools::test() to run the test scripts on the new version of the package.