First of all, thanks for thinking about contributing to the wdpar R package! This is an open source project, and contributions are extremely welcome.
There are several ways you can contribute to this project. If you want to know more about why and how to contribute to open source projects like this one, see this Open Source Guide.
Using the package and got stuck? Browse the documentation to see if you can find a solution. Still stuck? Post your question as an issue on GitHub. While we cannot offer user support, we’ll try to do our best to address it, as questions often lead to better documentation or the discovery of bugs.
Want to ask a question in private? Contact the package maintainer by email.
Have an idea for a new feature? Take a look at the documentation and issue tracker to see if it isn’t included or suggested yet. If not, suggest your idea as an issue on GitHub. While we can’t promise to implement your idea, it helps to:
See below if you want to contribute code for your idea as well.
Using the package and discovered a bug? That’s annoying! Don’t let others have the same experience and report it as an issue on GitHub so we can fix it. A good bug report makes it easier for us to do so, so please include:
Noticed a typo on the website? Think a function could use a better example? Good documentation makes all the difference, so your help to improve it is very welcome!
This website is generated using the pkgdown package. That means we don’t have to write any html: content is pulled together from documentation in the code, vignettes, Markdown files, the package
_pkgdown.yml settings. If you know your way around
pkgdown, you can propose a file change to improve documentation. If not, report an issue and we can point you in the right direction.
Functions are described as comments near their code and translated to documentation using the roxygen2 package. If you want to improve a function description:
Care to fix bugs or implement new functionality? That’s brilliant! Have a look at the issue list and leave a comment on the things you want to work on. See also the development guidelines below.
We try to follow the GitHub flow for development.
git pull upstream master.
devtools::check() and aim for 0 errors and warnings.