The goal of this guide is to help contributors to {interplex} plan their contributions and navigate the process. The sections below cover different types of contributions, usually with increasing degrees of proposed change.
Note that {interplex} is released with a Contributor Code of Conduct. By contributing, you agree to its terms.
This guide is copied from the contributing guide for {ggalluvial}, which was loosely adapted from those for {ggplot2} and from ropensci. If you have questions about or suggestions for this guide, please feel free to contact a package maintainer.
Small edits to comments, documentation, and other non-code files may be made using the GitHub file editor. To edit {roxygen2} documentation, make changes to a source file R/<topic>.r
, on a line that begins with #'
, rather than to a documentation file man/<topic>.Rd
.
For more guidance on {roxygen2} documentation, see this chapter in the online book R packages.
Questions, possible bugs, feature requests, other open-ended issues may be raised as issues on GitHub. In most cases, the issue should consist of two sections: a description of the issue, and a reproducible example of it. A reproducible example should attach packages, include data, and execute code:
-
Attach all relevant packages at the top of the example.
-
Use as small a data set as you can conveniently get that illustrates the issue. Once you have such a data set, the best way to include it in the example is to re-create it using
data.frame()
or some other constructor function. Another way is as follows:- Execute
dput(data)
in R, wheredata
is the data set. - Copy the output.
- Paste into the example after the package attachments.
- Execute
-
Use as few lines or steps of code as feasible to illustrate the issue. Add comments at key steps.
For more guidance on reproducible examples, see this vignette for the {reprex} package.
Bug fixes, feature upgrades, and other substantive, self-contained changes may be contributed via pull request. Unless previously discussed with a maintainer, please follow these steps:
- Fork the home repository (
tdaverse/interplex
). - Create a new (local) branch on which to make changes. If appropriate, update the documentation on this branch and run functionality checks (e.g. using the {devtools} package).
- Push this branch to the fork and open a pull request to the home repository.
- With the maintainer(s), discuss and (if necessary) update the pull request until it is accepted or decided against. In the latter case, a clear and consistent reason should be provided by the maintainer(s).
For more guidance on the pull request process, see the contributing guidelines for {ggplot2}.