---
title: "R Can Use Your Help: Reviewing Bug Reports"
author: "Tomas Kalibera, Luke Tierney"
date: 2019-10-09
categories: ["External Contributions"]
tags: ["debugging", "bugs", "bugzilla"]

---

```{r setup, include=FALSE}
knitr::opts_chunk$set(collapse = TRUE)
```

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](https://bugs.r-project.org).

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](mailto: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](https://www.r-project.org/bugs.html)) may be a good idea.

  - Find some reports where a reproducible example is missing or too
    complex.  The [R
    FAQ](https://cran.r-project.org/doc/FAQ/R-FAQ.html) and the
    [Reporting Bugs link](https://www.r-project.org/bugs.html) on the
    [R home page](https://www.r-project.org/) 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.