User guide for open source project bug submissions

No readers like this yet.
annoying bugs

Opensource.com

I recently announced a call to action for GNOME 3.10 Test Day for Fedora 20 on Facebook and I got a response that caused me to think about how everyone from the general public to developers submit and fix bugs for an open source project.

This was the interaction:

Me: Everyone, lets test GNOME 3.10 and Fedora 20 tomorrow!

User: Not sure if that helps but when I'm logged in on my laptop and suspend it there's no way to log in back. This is on Fedora 19.

Me: File a bug then.

User: I'm just giving you an idea to test. And I think the bug tracker requires an account.

Why submit a bug to Bugzilla?

The developer to user ratio is 1:100, or even more sometimes, so a tracking system like Bugzilla must be used in order for problems to get solved, for bugs to get seen and fixed. This will also ensure that other users are aware of the issue. If it is common across different hardware, others will add more information this helps resolve the problem more quickly.

The interaction I had with the user above also highlights that some users might not want to create a Bugzilla account in order to file the problem/bug. But, if you see a problem and don't report it, it may not be fixed for quite some time. Reporting bugs is also a chance to contribute back to the open source project you are using.

The reality is that both developers and quality assurance agents are a scarce resource for any open source project. They have their own plans and goals to meet on a deadline during the launch of a new product. So, though it might be easy to just "tell" someone via social media or chat or even in person, the best course of action is to file a bug in the tracker system being used for that open source project.

The open source project mindset

The Open Source Director at Google, Chris DiBona, sums up well how the open source community (of developers and users) works (and why it can sometimes be 'brutal'):

I think that it is because open source projects are able to only work with the productive people and ignore everyone else. That behavior can come across as very harsh or exclusionary, and that's because it is that: brutally harsh and exclusionary of anyone who isn't contributing.

So, I guess what I'm saying is that survival of the fittest as practiced in the open source world is a pretty brutal mechanism, but it works very very well for producing quality software. Boy is it hard on newcomers though...

Each member of the open source community invests lots of their free time and resources in developing and making a project successful. So, it's important that streamlined ways of getting things done are implemented, from start to finish; and that everyone plays by those rules.

To submit a problem / file a bug:

  • login to the tracker system being used (like, Bugzilla)
  • create a test case
  • describe the steps to reproduce to problem/bug
  • bonus: if there is one, add it to the Test Day wiki page; then, if others have the free time they can test it where possible

Open source projects are fun and challenging. And, the best way to participate, and we hope you do, is to lend a hand when possible. Every contribution counts!

User profile image.
Alex is a QA contractor at Red Hat responsible for over 1400 bugs, a general purpose open source developer and an entrepreneur. He lives in the Sofia Valley which is emerging as a busy place for start-up founders and tech hackers in Eastern Europe! Twitter: @atodorov_

9 Comments

There is a problem, as stated in the article. You need a login to the tracking system to properly report bugs. This works fairly well if the people reporting bugs are developers or of a similar mentality, but what happens as Linux becomes more popular?

I know for a fact that on Ubuntu systems, where the bug system is automated, most people cancel out... because "it's too complicated". The same thing happens on Windows, and I'm pretty sure Microsft makes it even easier, because they don't care about your privacy.

I don't actually have a solution, I'm just pointing out some of the issues, I've seen.

You are right, but I have no idea why this is a problem.

People seem to have no issues registering new accounts whenever new and cool services appear on the web, but will resist registering an account on a bug tracking system. Not sure why is that.

You are right with "registers for cool", but most often that is for services that they think they may use again (or have been using for some time without account).
The underlying issue is that users see a bunch of issues with registering and filing the bug and just don't think it is that important.

One option could be to allow for anonymous bug posting - like the reports that go to the Android play store account. You can't really get back to the user, but at least that issue is recorded in the bug tracker.

And then single signon helps: users that have an account on community.jboss.org can also use that for the Jboss.org Jira bugtracking instance.
And now to go back to "cool" - if submitting a (new) bug would also get points for the achievement/badge system, there would even be an incentive to go through the hassle of bug filing.

Another thing is that filing the bug itself is often too complicated. You have to choose a category, perhaps a severity etc. Especially the Bugzilla user interface can be very frightening to new users.
Here the category could be set up as default "- don'tknow" which goes first. This will put a somewhat larger burden on the developers to correctly file the issue, but it prevents the user from giving up at that point (and then if the user selects a category, it may be totally bogus anyway).

I see you citing Chris DiBona "open source is a hard business" - but do we really need to keep it that way?

The information alone that the user was giving is a valid issue, that needs some checking, so if the user does not want to get an account for the bug tracker, we as the ones with an account, can also just go ahead "hey, no probs, what exact computer model do you have .... " and then open a bug with that information and give the user the URL to it.

It is also possible to introduce another 'level' between the Users and Developers. Checkout the Joomla Bug Squad: http://docs.joomla.org/Bug_Squad

They check forums, help users with their issues, triage the tracker etc. They also file bugs for users at times. It takes away the extra work/burden on developers, and the user is getting help.

We've had one of those, more than once. It always dies. I know of a very few projects with somewhat successful ones, and many more projects with dead/dormant/stillborn ones. It seems to be one of those tasks that is sufficiently dull and thankless that it's hard to get people to do it for very long.

I wrote the below notes (obvious information, just spelled out loud) after triaging bugs that were woefully short of *useful* information or lacking relevant context
https://wiki.openstack.org/wiki/BugFilingRecommendations

(It also has URLs to Fedora and mozilla communities practices of bug writing guidelines.)

hey thanks Alex for submitting helpful article for opensource developer, its really good for me and my friends for our developing projects, i face many problems and also got the help from leaders for this, but here you post article for resolve the problems. I really like to read more on this if you have than share with us..

IMO login with facebook/google/etc. can greatly reduce new account creation hurdles. But make sure that you don't want my friend list and all kinds of other privileges, otherwise I wont play with you!

Also a problem with reporting bugs is lack of interest from developers. Sometimes users are even asked to provide a lot of information that costs time to collect. And then nobody cares to do anything with it... just telling the opposite side.

And maintaining a package not developed by you is even worse because you don't have full control. Sad thing is that often the upstream developers are not very interested in fixing stuff and then everybody in the chain is discouraged.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.