The number of open bug reports in the R bug tracker has been reduced by about 25% during August and September this year. This work has been possible thanks to an investment of the Sovereign Tech Fund.
Urgent bug reports that are easily reproducible, ideally coming with a small reproducible example, are typically resolved quickly. Other bugs, however, can remain open for a long time. As the backlog grows in size, it becomes hard to navigate, even though it still contains some real bugs experienced by users. Larger is the backlog, harder it is for core developers to find the real bugs. Also, all genuine (non-spam) reports probably deserve a response, even if a negative response, and particularly those that involved non-trivial effort from the reporter.
The primary goal of this work was a significant reduction of the backlog, so initially it focused on reports that were easiest to resolve. This included real, reproducible bugs that were easy to fix or came with patches easy to review.
Also, some reports were closed without any fix: reports not reproducible and no longer relevant, invalid reports, requests for changes not desirable (or not in line with the documented behavior, breaking back compatibility, etc). The goal was to always provide a clear explanation why a report was closed, also to help reporters focusing their energy in future reports. While no bug report was closed simply because of being old or inactive, it was a factor that contributed to the decisions (here I mean inactivity of years or many years; some projects close bug reports automatically due to inactivity for much less than that).
The secondary goal was to also fix or at least analyze some real bugs not necessarily easy to fix. In some cases this lead to new comments in bugzilla, in some cases I’ve alerted core developers who have better expertise for the reports.
Six years ago, there was a call for external help with reviewing bug reports. The advice provided to potential external volunteers still applies. I would add that it also helps reviewing comments in the bug reports: when a bug report discussion ends with a technically invalid comment, it can mislead people trying to navigate the bug backlog. It helps when that is corrected.
The plot (thanks to Sebastian Meyer) shows the number of open bugs and number of comments in the R bug tracker from October 1, 2019 to September 30, 2025. It is a variant of the plot in Kalibera & Meyer, “Changes in R”, The R Journal, 2024 and such summaries provided in the previous years.
The plot hence shows the number of open bug reports during the last 6 years, starting with increased bug-fixing activity supported by help of external volunteers in 2019 and ending with this work in 2025.
One of my observations based on this work is that it is surprisingly difficult to find a report one can help with. It is hard to tell just from a quick look at each report, so one can easily end up spending more time reading and analyzing reports one cannot help with in the end. This is another consequence of having a large backlog which is harder to navigate, and this work reduced the size of the problem, yet over 400 open reports still seems more than ideal.
Perhaps unsurprisingly, some of the re-discovered very old bug reports were about bugs still present and reproducible in the current version of R.
During this work, I experienced again that on Windows, where CRAN provides binary distributions of R, and where back-compatibility is regarded as very important by the OS, it is possible today to still run an R version more than 10 years old (that is, R using base and recommended packages only).
Another observation was that the classification of the bug reports often seemed wrong, while at the same time it was clear that in some cases, it is often a matter of opinion how to classify. Certainly the classification wasn’t very helpful for guiding the analysis of the bug backlog. It is not surprising that the reporter and R core developers tend to have different views on importance of a bug, but some wishlist items were classified as bugs, and I’ve even seen a real, obvious bug being classified as a wishlist item.
This work is recorded in the R bug tracker. It can be viewed via the web interface, for example via “Advanced search”, and for computing on the bugs, one can use the Bugzilla API.