The goal of this guide is to help you contribute to DemoTools as quickly and as easily possible. The guide is divided into two main pieces:
Before you file an issue:
Check that you’re using the latest version of DemoTools. It’s quite possible that the problem you’re experiencing has already been fixed.
Check that the issue belongs in DemoTools. Some functionality lives in separate packages.
Spend a few minutes looking at the existing issues. It’s possible that your issue has already been filed. But it’s almost always better to open a new issue instead of commenting on an existing issue. The only exception is that you are confident that your issue is identical to an existing problem, and your contribution will help us better understand the general case. It’s generally a bad idea to comment on a closed issue or a commit. Those comments don’t show up in the issue tracker and are easily misplaced.
When filing an issue, the most important thing is to include a minimal reproducible example so that we can quickly verify the problem, and then figure out how to fix it. There are three things you need to include to make your example reproducible: required packages, data, code.
Packages should be loaded at the top of the script, so it’s easy to see which ones the example needs.
The easiest way to include data is to use dput() to generate the R code to recreate it. For example, to recreate the mtcars dataset in R, I’d perform the following steps:
dput(mtcars) in Rmtcars <- then paste.But even better is if you can create simple objects such as those used in the function examples for most top-level methods in the package.
Spend a little bit of time ensuring that your code is easy for others to read:
make sure you’ve used spaces and your variable names are concise, but informative
use comments to indicate where your problem lies
do your best to remove everything that is not related to the problem.
The shorter your code is, the easier it is to understand.
Learn a little [markdown][markdown] so you can correctly format your issue. The most important thing is to surround your code with ``` R and ``` so it’s syntax highlighted (which makes it easier to read).
Check that you’ve actually made a reproducible example by using the reprex package.
If you have something to contribute, please fork the repository, make the change in your fork, and then make a pull request.
Your pull request will be easiest for us to read if you use a common style: http://r-pkgs.had.co.nz/r.html#style. Please pay particular attention to whitespace.
You should always add a bullet point to NEWS.md motivating the change. It should look like “This is what changed (@yourusername, #issuenumber)”. Please don’t add headings like “bug fix” or “new features” - these are added during the release process.
If you can, also write a test.
If you’re adding new parameters or a new function, you’ll also need to document them with roxygen2. Make sure to re-run devtools::document() on the code before submitting.
Also run devtools::check() to make sure your function doesn’t imply downstream errors or warnings. More such checking will be taken care of by us.
Here are tips for syncing your fork with the main repository syncing
A pull request is a process, and unless you’re a practiced contributor it’s unlikely that your pull request will be accepted as is. Typically the process looks like this:
You submit the pull request.
We review at a high-level and determine if this is something that we want to include in the package. If not, we’ll close the pull request and suggest an alternative home for your code.
We’ll take a closer look at the code and give you feedback.
You respond to our feedback, update the pull request and add a comment like “PTAL” (please take a look).
Don’t worry if your pull request isn’t perfect. It’s a learning process and we’ll be happy to help you out.
It can be frustrating that your PR is ignored for some time, but it will eventually make it into the package in one way or another.