---
title: "Reducing the Backlog of Open Bug Reports"
author: "Tomas Kalibera"
date: 2025-10-13
categories: ["External Contributions", "User-visible Behavior", "Internals"]
tags: ["debugging", "bugs", "bugzilla"]

---

```{r setup, include=FALSE}
knitr::opts_chunk$set(collapse = TRUE)
```
The number of open bug reports in the [R bug tracker](https://bugs.r-project.org/)
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](https://www.sovereign.tech/tech/r-project).

![](../../../../post/reducing-the-backlog-of-open-bug-reports/open.png)

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](https://blog.r-project.org/2019/10/09/r-can-use-your-help-reviewing-bug-reports)
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](https://journal.r-project.org/news/RJ-2024-2-rcore/) 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](https://bugs.r-project.org/).
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.
