Mozilla Bug Reporting

I read an entry on LiveJournal by Zwol entitled “On the Unfriendliness of Bug Reporting”. Zwol wanted to input a new bug he found in Firefox. However there were a lot of confusing points in the bug submission process. You have to decide which component to file the bug under. It is not intuitively obvious which option to choose. Some large categories already have a lot of bugs under them. There are other strange choices on the bug submission screen that have users giving up on the process.

Another part of the problem is the sheer number of fields on the bug report screen. Sure you want to add all the information you have. Zwol recommends a special developer mode for the bug reporting screen. That way the devs can see all the fields they need, and the average user can just enter the simple information to get the bug submission done.

The Mozilla team replied in the comments section of the blog on LiveJournal. They said they are working on the problem. A group of students have been assigned this task. That sounds good given the fact that they are an open source project. Perhaps they were already thinking about improvements to the bug submission screen.

On my project, you also have to go through a lot of hoopla to submit a bug report. New testers have a lot of trouble getting this right. The result is that bugs get lost of channeled to the wrong developers. Our bug submission screen is not only large, it has many screens to boot. This does have some advantages. When you know what you are doing, you can add a lot of important information about a bug. You can attach screen shots of the problem. And you can really specify a lot of characteristics of the bug.

I would think that a product made available to the general public at large should have a much simpler bug submission page. Being an open source project, I bet they roll their own open bug tracking system. And they probably developed their own bug submission screens. Who is the developer going to write those screens for? Unless care is exercised, it is probably not geared toward the casual home user who finds a problem. Maybe it needs to be.

Customer Trouble Tickets

A trouble ticket tracking system may have a short term goal of keeping tabs on software defects. However this is usually a means to another end. You don't track problems for the heck of it. You do it to ensure the users of your product can do their jobs. The Software Maintenance blog has a story about and developer and his trouble tickets.

This developer is staying proactive in making sure customer problems are being solved. Too many times a problem falls between the cracks. It takes an active effort to make sure all problems are prioritized and worked. A bug tracking system can help with this. But you need a process built around it to ensure the best results. You also need some level of diligence in the users of the tracking system.