User guide for open source project bug submissions

User guide for open source project bug submissions

Eliminating bugs.
Image by :

Subscribe now

Get the highlights in your inbox every week.

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!

About the author

Alexander Todorov - 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!...