## Contributor Code of Conduct

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

## For the General Public

If you’re not a member of the Weecology lab, 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.

## Weecologists

If you’re actively working on this repo, then you should have write access. For anything beyond a minor change to documentation or coding files, please create a branch for any new features or bugfixes and create a pull request when you’d like your work to be merged in.

## Documentation

If you are contributing code to this project, you generally don’t need any additional packages, since the documentation will be written as comments in the R scripts. If you are also building the package, see the section below 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.

## Building

To fully build the package, including documentation, running-tests, you will need the roxygen2, testthat, devtools, pkgdown, and usethis R packages.

Specific operations are then done by calling the appropriate functions from within R, while your working directory is somewhere in the package folder.

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.
4. Run pkgdown::build_site() to update the pkgdown site built from the documentation.

If you are also prepping the package as a whole, then you will also want to run devtools::check() and/or devtools::check_cran() to make sure that the package is complete.

For more info, see the GitHub repo for the devtools package.

## Contributing Data

We use a specific data structure that handles community data and optional covariates. For more information, please see the related vignette.