After understanding where bugs are reported in R (Bugzilla) or in other projects (GitHub/GitLab/R-Forge), a great way to contribute is reviewing bug reports.
Around the clock, new bug reports are being submitted on Bugzilla or the bug trackers (for instance, GitHub issues) of R packages and existing bug reports are being updated. Every bug report needs to be reviewed to make sure various things are in proper order. You can help with this process of reviewing bugs.
Base R uses Bugzilla for issue tracking. In order to report bugs, as well as fixes, you will first need to create an account on Bugzilla. After having successfully logged in to Bugzilla, you are good to go.
An image of the existing home page of Bugzilla is shared below:
On the home page of Bugzilla, there are various buttons and links. There are four square buttons called as:
File a bug: You will have to log in to Bugzilla to file a bug using this button
Search: When you click this button you will get a page with ‘Simple Search’ and ‘Advanced Search’ options. Either of the search options could be used depending on what you are looking for.
Log In: Provide the appropriate email address and password here to log in to Bugzilla.
Documentation: Provides a user guide for R's Bugzilla.
Several useful shortcuts are available from the landing page:
A quick search bar is available on the home page where you can enter a bug number to search or some search terms.
There is also a section for Common Queries on the home page which includes links to bugs reported and changed in the last 24 hours and last 7 days.
If you want to review bug reports on Bugzilla, you are required to have a Bugzilla account. To get a Bugzilla account send an e-mail to
email@example.com from the address you want to use as your Bugzilla login. Briefly explain why you want a Bugzilla account and a volunteer will add you to R’s Bugzilla members. More details on how you can review a bug report are available on this blog
A good bug report is the one which:
Explains clearly how to reproduce the bug.
Includes the version of R, the machine architecture, and the operating system platform on which the bug occurred.
Relevant details should be a part of a good bug report. You can help with the following tasks once you have some R programming experience:
Reproducing the bug: If you see a bug report which does not clearly explain how to reproduce it, you can try reproducing the bug and eventually make things easier for the core developer(s) and/or package maintainer(s).
Checking different binary builds: Check whether the bug occurs on a different binary build of R. It is helpful to know whether the bug is affecting:
r-releasebinary builds of R.
Writing a unit test: If the bug report lacks a unit test that should be a part of R’s test suite, then you can help with providing it.
These helpful tasks allow the Core developers and/ or maintainers to classify a bug report properly, so that the bug can be handled in a timely fashion.
You may search old bug reports or issues that could be closed. Old bug reports may no longer be valid or may include a patch that is ready to be committed, but no one has had the time to review and commit.
You might also want to search for issues in topics in which you have a working knowledge. When on Bugzilla you can use the advanced search to find specific topics. Bug reports are by default public on Bugzilla (unless the defaults are changed to avoid security vulnerability).
If you would like to see how bugs are reviewed on Bugzilla, here is an example where an old bug report is being reviewed. It is tested to see if it was still an issue and a few ways are proposed to resolve the issue.
There is a
#bug-reporting channel on the R Contributors slack where you can share your bug report(s) for review/feedback before submitting to Bugzilla. This can help with checking that it really is a bug, that you have included the important information and excluded redundant information.