A simple way to report a bug is to email a report to Dan Kelley@Dal.Ca. However, people who are comfortable with web interfaces are highly encouraged to instead use the development site to report bugs, because that makes it much easier to track the bug fix. The development site also lists previous bug reports, so it can be a good place to look to see if your bug has already been reported.

The best issues are granular (one issue report per problem), and are stated with a subject line that is short and clear. This yields two benefits. First, it lets other users scan issue titles to see if an issue has already been reported. Second, it lets the developers address issues in isolation, which generally leads to more reliable results.

The interchange of comments on issues can be carried out with the web interface or with an email interface. In the latter case, reporters are cautioned to avoid letting their email program auto-include signature lines with phone numbers, etc. This is a privacy concern. Generally, the developers will edit such comments. The developers also delete conversational comments ("Still broken?" "Yup." "How about now?" "Good, thanks.") that will not interest other users on another day.

It is helpful if issues contain (a) test code that demonstrates the problem but does very little else, (b) a statement of the expected result, (c) a statement of the actual result, (d) the output from the R command sessionInfo().

The issue-reporting site is not a good place to submit large or confidential data files. These should instead be sent separately to the developers, who can keep them confidential.

This website is written in Jekyll, and the source is available on GitHub.