The ability for users to submit patches is often touted by advocates of open source software. “Patches welcome!” is a common refrain on mailing lists. Even if someone lacks the ability to diagnose and fix an issue, they can file a bug in the project’s system. Indeed, there’s an unwritten social expectation that users file a bug.
Sadly, these are often just empty words. “Patches welcome” can be a seemingly-polite way of saying “your problem is not important to me. Go solve it yourself and I’ll accept your solution.” And telling a user to go file a bug can be equally dismissive, especially if the bug-filing process is unpleasant.
I certainly don’t mean to imply that all or even most open source developers use these phrases as a polite cover for their disinterest. There are jerks, of course, but I suspect most developers genuinely want bug reports and patches. Last week, a very busy developer replied to a mailing list post with a terse “file a bug.” Now, I happen to know this particular developer and I know he’s keenly interested in fixing bugs. On this day, he was swamped and didn’t have time to get to the issue right away. Suspecting from the original email that the user who reported the bug wasn’t deeply technical, I took the liberty of reproducing the issue and filing a bug with the details.
Would the person who originally reported the issue have filed the bug done so if I hadn’t? We’ll never know, but I do know that he didn’t by the time I did. After creating a Red Hat Bugzilla account, selecting the right options, and filling out the bug report, he’d have to hope the developer meant it and that he bug would get fixed. As anyone who has been around a while can attest, just because a bug is filed, that doesn’t guarantee it will be fixed in the next few years.
One particular bug that I filed sticks in my memory. It was undeniably a bug, I attached a patch to fix it, and yet the bug remained untouched through several Fedora releases. Granted, it was a relatively minor issue, but if I weren’t involved with the project, I’d have been pretty put off by this. Of course, no one owes me a fix, but as Chris Siebenmann noted, if there’s a social obligation to file a bug, there’s also a social obligation to deal with the bug.
This morning,I asked on Twitter if anyone had what they’d call a “positive” bug reporting experience (as opposed to simply a not-negative experience). I was pleasantly surprised when several people chimed in to say they had. Small projects were generally the ones that drew the good responses (Jordan Sissel was mentioned by multiple people).
So what makes for a positive experience? Rapid acknowledgement and resolution were mentioned several times. Those who replied mentioned courteous and helpful interactions (e.g. asking constructive questions, filing an appropriate bug when the original bug was mis-filed). @phrawzty summed it up well: “Most importantly, however: good intentions were assumed. I never felt treated like a dangerous outsider.”
This is an area wide open for study (and I may end up doing just that), but in the meantime projects should consider how they present themselves. Large projects with more resources should make an active effort to devote some time to bug handling as a community outreach effort (I suspect large projects have worse bug experiences, in part due to the fact that nobody owns the process). When you say “patches welcome” or “file a bug”, consider what you’re really saying and if people will take it the way you mean it.
(Thanks to those who provided feedback: @cpj1, Matt Simmons, Matthew General, Patrick Cable, @phrawzty, Rick Waldron, @SysAdm Dredd, Thomas Ballinger, @Twirrim, and anyone else I failed to mention.)
I am probably wrong here, but the bugs i file are most of the time by nature there due to low priority. They exist because they were
a side effect of some other change. The change has priority, but some of the issues it introduced not necessarily.
My overall experience makes me hesitant to file bugs, “Patches welcome”, “file a bug”, are some of the things.
Having to endlessly explain why something is a bug, Different views of what is a bug is also a big issue for me. The stuff i do
is usually pretty exotic, and issues i find are often invisible to most. Potentially having to answer hard questions or having to
do things one might no be familiar with like adding gdb data. Or plainly not getting any response at all.
I am ashamed to say that over the years i have developed a , don’t bother, just work around it, attitude. That was inevitable because
of difference in opinion. Often even if i were to implement a “fix” myself it would not be accepted either by the distribution or
upstream, or both because it is based on a fundamental difference of opinion with the maintainer(s).
(i know that some distribution maintainers have the same issues sometimes with upstream, where they just dont upstream because they
know they took a different path that is unacceptable by upstream)
It got to the point where it affects my experience with computing. I have an attibute of: if you do not have it then it cannot break,
So most of my systems are minimal rawhide systems. No fancy stuff. Some components that matter to me I have forked or replaced by my
own implementation that i maintain myself.
I suppose it is mostly about priorities.
Nowadays, I use IRC for “reporting my bugs”. I just mention the issue in the appropriate channel and forget about it/work around
it if is a requirement. If someone replies “patches welcome”, then i reply with “Thanks, duly noted”. If someone replies with
“can you file a bug report, please”, then i answer with “I would , but i lost my password to bugzilla” (which is actually the truth,
i just don’t bother creating a new account or go search for the password in my stack of notes. knowing that probably in a year i
will be in the same position (i change mail address often and just forget about my old addresses))
Bugzilla is also reasonably unpleasant, and that is also is a barrier for me. Not just bugzilla though. The same goes for
ask.fedoraproject.org and many other sites. The authentication/registration is just sometimes a bridge too far for me. I realize
that anonymous bugreports or anonymous answers on ask.fedoraproject arent feasible but registration/authentication poses a
barrier no less.
There are really awesome people and groups of people out there too, It must be said. And it must also be said that I myself am
sometimes to blame. Bugs can sometimes be frustrating, and we are all only human after all.
Just knowing that your priorities do not align with the priorities of the distribution will do that.
@domg472 thanks for your comment! I can empathize with your experiences, and it’s unfortunate that we, as open source communities, still make would-be contributors go through this. You’re absolutely right that Bugzilla is a pretty painful mechanism for casual bug reporting, but it’s probably not the root of the issue.
As you alluded to, it seems like the main issue is one of perception and interaction. If you don’t feel like your contribution is valued (because it’s incomplete, misaligned with the project, whatever), you’d be crazy to keep contributing. Much of the solution comes from how the project is governed (more on that in the coming weeks), and the amount of effort that the project puts into making the bug experience pleasant.
I gave up on filing bugs for Fedora and PHP. Most of the ones I did file got closed because the release where they were found by me went obsolete. I also don’t find bugzilla a problem, dealing with no answer for months/years is a bigger problem. Closing as WORKSFORME is also very annoying.
I used to be an active Fedora packager for some packages and I tried to keep my bug list small and respond quickly.
I also had a few good experiences with bug reporting, mostly on Github, which is also the place where patches really are welcome.
@Christof. Thanks for your comments. Sadly, your experiences aren’t unique. I wonder if it’s due in part to the fact that many distribution package maintainers (how many, I wonder) aren’t the upstream developer. On GitHub, you tend to get more directly to the developer so that may explain the better responsiveness.
It seems to me that larger projects should have dedicated, visible teams responding to bugs and ensuring they get to the right people. Unfortunately, since most of the effort would be volunteer, finding people to willingly take on that role is tough.
I’ve submitted various bug reports over the years.
My best experiences, many years ago were bug reports and feature requests to the defunct cmu-snmp-linux project. I included patches and those patches were adopted.
I have also submitted patches to axis2 and libesmtp, which weren’t used directly, but they seem to have prompted fixes. In the case of axis2 there was a long standing bug that had been discussed but no action taken until I submitted a patch. Unfortunately my patch wasn’t against the current code and couldn’t be used, however once I’d submitted a patch, the developers then created a fix for the current code.
Most of the bug reports I have submitted without accompanying patches have disappeared without trace, however a bug I reported in KDE3 was eventually fixed in KDE4 about 3 years later.
My bug report to Apple has been ignored for the last n years and I don’t expect that to change.
A free sw project should not have a bug tracker unless there is enough organization behind to actually service the reports IMO. Unfortunately many hosting sites have the mentality that they throw in one for free in every project since it “can’t hurt”. Also I don’t know if putting a bulky database system between the users and the developers, which makes sense in the commerical world, really makes the best use of the strength of the free software community.
Something more lightweight and free form would be better in many cases. An interface something like this very blog commenting interface could be appropriate. Here I just write what I think and I don’t feel any social expectation that you will reply to it (but would be fun if you did).
@swordfish “Most of the bug reports I have submitted without accompanying patches have disappeared without trace” it’s a shame that that seems to be a pattern. I think it drives away a lot of potential future contributors, not to mention driving away current users.
I’m with you on Apple. It seems like in most cases proprietary software companies generally don’t respond to bugs that don’t have a corresponding contract (and even then…)
@magnus: You’ve challenged a deeply(-ish)-held belief of mine: that bug trackers are a necessary component of an open source project. I suspect that you’re right, though: an ignored bug tracker is probably worse than none at all. Even though I sometimes really appreciate the power of something like Bugzilla, I think systems like GitHub’s issue tracker are probably better for casual users in almost every case. I’m going to have to think about this some more, so expect to see ramblings on this topic in a future post. 🙂
GitHub get better response, not only because it is more “direct” to developer.
The bug reports on github are generally have higher quality.
People with github account tends to be developers. They know how program works.
Developers are equally frustrated by low quality bug reports, just check the Android bug tracker — http://code.google.com/p/android/issues/list?can=1
The latest “bug” on the tracker is “i have a bug or spy — Somebody has been bugging my phone and car”. Ugh.
In commercial company, they hire people to do all the dirty work and filter out these “bug” reports. How do you motivate volunteers on do this?
@Daniel, you’re right that GitHub users tend to be developers (to some degree or another), but I would guess the same could be said for various Bugzilla instances and whatnot. That’s both a blessing and a curse, since non-technical users can still still submit helpful bug reports (though they sometimes require coaching on how to do that). Certainly a healthy community needs a way for non-coders to provide good feedback.
As for how to make this happen in a volunteer-driving community, that’s a tough question. I think part of it is that the community has to set a culture of emphasizing prompt bug triage. It has to be a part of the community ethos. Undoubtedly there are people out there who would be willing to contribute in that effort, so it’s a matter of finding them and encouraging them to participate. It might also be a good way for new contributors to start on a project before moving into deeper areas.
These answers are, admittedly, very hand-wavy and not helpful. I’m hoping to spend some time doing some actual research on this subject in the coming months.
If you want me to make an account, unless I’m really bored I’ll just leave. If you want me to reproduce on the dev version or whatever isn’t my current version I’ll leave. I don’t mind doing a search for past bugs before reporting but if I’m in the middle of something I’ll just leave. If reporting takes too long I’ll get distracted and leave.
In the end unless I truly deeply want to report and you can keep my interest through the process I’ll leave.
Now I’m going to leave. Seeya.
Apologies if this is too late to be relevant, but I’ve had a mix of both positive and negative experiences filing bugs. I think of most of them as positive though, because they ultimately resulted in me learning something about the project. Regardless of whether I was just able to fix the problem for myself or I had gained sufficient context to create a fix that the author or maintainer thought was reasonable in the greater context of the project.
Fedora seems particularly tricky because of their bug housekeeping practice. If you aren’t willing to babysit the issue by testing for it in subsequent releases or verifying it in the developmental release it will likely languish. Another tool to resolving issues like that is to ask more seasoned developers what they might recommend for a best way to get your issue dealt with. Often times this is most easily accomplished on IRC or a mailing list.
@opello: It’s never too late to be relevant, thanks for reading! I agree that something being fixed is important and generally satisfying. My concern is that even if the bug does end up getting fixed, the bureaucratic hassle of the process can make someone think twice about filing their next bug.
Fedora’s bug tracker is particularly rough, as you alluded to. The tools and process are helpful for developers, but the user experience is rough. Any distribution that wants users that aren’t developers has to consider the bug workflow.