If you use R you may have wondered if there are ways you can contribute to making R better. This is the first in several posts on how you might help. This post is about helping to review and resolve bugs reported on the R bug tracker.
Urgent bug reports, in particular ones with simple reproducible examples, are generally resolved and closed quickly. But those that are not can sometimes languish for a long time. At the time of writing there were 579 open bug reports in the bug tracker. Some reflect issues that have already been resolved or no longer apply, some may be valid but are too hard to track down because of the complexity or lack of a reproducible example. Others reflect a misunderstanding of documented behavior that ideally should be communicated to the reporter.
To allow us to focus more of our resources on improving R and to also make the bug reporting process more responsive we could use your help with reviewing and handling reported bugs. If you would like to help, here are some of the things you can do:
If you do not already have a bugzilla account send an e-mail (from the address you want to use as your login) to bug-report-request@r-project.org briefly explaining why, and a volunteer will add you to R’s Bugzilla members.
Review some of the older reports and identify ones that have been resolved or no longer apply for other reasons and add a comment to the report explaining why so that a Bugzilla member with the necessary permissions can close it.
Identify cases where a bug report reflects a misunderstanding of documented behavior, write a comment explaining this to the reporter, and suggest the bug can be closed.
Sometimes a report like this may suggest changing documented behavior. This is often hard because of our strong commitment to backwards compatibility, but is sometimes possible. Opening a “Wishlist” item (documented in Reporting Bugs link) may be a good idea.
Find some reports where a reproducible example is missing or too complex. The R FAQ and the Reporting Bugs link on the R home page provide some good advice on creating good bug reports.
In the process you may find that there is no bug and the report can be closed. You may also find that there is a bug but in a contributed package. This can also be closed, ideally after the maintainer has been notified.
If it turns out that there is a bug in R, then the key to resolving it is producing a simple reproducible example that clearly identifies the bug. This can often be done using just R code, on rare occasions after looking at internal C code that this R code would execute. This is generally the most time consuming process of tracking down a bug, and where we could most use your help. Actually fixing the bug once it is clearly isolated is usually straightforward, so you should not feel you need to come up with a patch. But narrowing it down in this way would be very helpful.
There may be some bugs where you will need some knowledge of C programming to precisely identify the problem, but for most you will just need to work at the R level.
By helping with these things you will be contributing to R by making R more reliable and also releasing R core developer time for focusing more on new developments and improvements. You will also improve your R skills and learn more about how R works.