.github/CONTRIBUTING.md

In leeper/prediction: Tidy, Type-Safe 'prediction()' Methods

Contributions to prediction are welcome from anyone and are best sent as pull requests on the GitHub repository. This page provides some instructions to potential contributors about how to add to the package.

1. Contributions can be submitted as a pull request on GitHub by forking or cloning the repo, making changes and submitting the pull request.

2. This package follows the cloudyr project style guide. Please refer to this when editing package code.

3. Pull requests should involve only one commit per substantive change. This means if you change multiple files (e.g., code and documentation), these changes should be committed together. If you don't know how to do this (e.g., you are making changes in the GitHub web interface) just submit anyway and the maintainer will clean things up.

4. All contributions must be submitted consistent with the package license (MIT).

5. Non-trivial contributions need to be noted in the Authors@R field in the DESCRIPTION. Just follow the format of the existing entries to add your name (and, optionally, email address). Substantial contributions should also be noted in inst/CITATION.

6. The package uses royxgen code and documentation markup, so changes should be made to roxygen comments in the source code .R files. If changes are made, roxygen needs to be run. The easiest way to do this is a command line call to: Rscript -e devtools::document(). Please resolve any roxygen errors before submitting a pull request. The README.md file is built from README.Rmd; changes should be made in both places or to README.Rmd and then knitted using using knitr::knit("README.Rmd").

7. Please run R CMD BUILD prediction and R CMD CHECK prediction_VERSION.tar.gz before submitting the pull request to check for any errors.

Some specific types of changes that you might make are:

1. Bug fixes. Great!

2. Documentation-only changes (e.g., to Rd files, README, vignettes). This is great! All contributions are welcome.

3. New functionality. This is fine, but should be discussed on the GitHub issues page before submitting a pull request. Note, in particular, that contributions of new prediction() methods, should comply with following:

4. Methods should be added to their own file in the R/ directory, with a file name corresponding to the function name (e.g., the prediction.lm() is saved in R/prediction_lm.R).

5. Lists of supported class are included in two places: README.Rmd (do not edit README.md directly) and on the main documentation package page (generated from roxygen comments in R/prediction.R). New methods should be listed in both places; methods are listed alphabetically by model class.
6. New methods should be supported by a simple test that is run conditional on the availability of the package that implements the model class. The tests should be added to the tests/tests-methods.R test file, under a conditional statement testing availability of package using requireNamespace(). Tests in this file are organized alphabetically, first by package and, within packages, by model class name.
7. Any packages that these methods require should be added to the Enhances field of the DESCRIPTION file. If methods require imports from a package they are supporting, they should still be listed in Enhances and call code should be made conditional on a requireNamespace() statement in the method.

8. The required packages should also be added to .travis.yml under the r_packages: heading so that they can be used during testing on Travis-CI.

9. Changes requiring a new package dependency should also be discussed on the GitHub issues page before submitting a pull request.

10. Message translations. These are very appreciated! The format is a pain, but if you're doing this I'm assuming you're already familiar with it.

Any questions you have can be opened as GitHub issues or directed to thosjleeper (at) gmail.com.

leeper/prediction documentation built on Jan. 1, 2020, 6:10 p.m.