Handling bug reports for upstream projects
The larger and more complicated your software is, the more likely that the bugs your users encounter aren’t bugs in your software; they’re bugs in upstream libraries that you’re using. While this may come as a relief to you, it’s irrelevant to your users. After all, they’re still dealing with the buggy behavior. Because you’re the place that the bug shows up, they’ll probably file a bug report against your project. So what do you do with it?
Of course, you should start by making sure the bug is really in the upstream project.
But after that, you want to make sure the upstream project knows about it. In the ideal case, you can ask the reporter to report it directly to the upstream. The reason it’s ideal is because it keeps the person seeing the behavior in the loop. They can answer follow up questions or potentially try out bug fixes. But this mostly works if the person reporting the bug is both technically adept and also interested in following up on this.
If both of those conditions aren’t true, don’t just say “it’s upstream’s problem” and close the bug report. File a report upstream on behalf of the reporter. After all, if they’re hitting the behavior, chances are good that others are, too. “Bug concierge” is a good role for someone who is eager to help your project but not yet familiar enough with it to make direct contributions.
The other reason to keep the bug report open is that it indicates that the bug is still present. People may look at open bugs before filing their own, but they probably won’t look through closed bugs; keeping it open can help reduce duplicate reports. Once the bug is fixed upstream and incorporated into your next release, then it’s time to close the bug. (If you don’t ship the upstream software, then closing the bug report earlier is appropriate.)
This post’s featured photo by Neringa Hünnefeld on Unsplash.
