Archive for March, 2011

End-User Bugs on Bugzilla

Mozilla offers an opportunity normally not available to users of most software. The ability to submit bugs directly to the developers of the software and watch the progression of the bug. With this comes a responsibility normally not faced by software companies. Because users can report these bugs, it means that unless they are looked at, the reporter and other user’s experiencing the issue quickly become frustrated that they are being ignored. The whole benefit of having end-users be able to watch the bug process can bite Mozilla in the tail. It frequently seems that the trend in Bugzilla is to divide bugs into quickly fixed and never fixed.

Bug Species

Bugs reported by regular end-users fall into one of two species.

  1. Not a real Firefox bug. Extension issues, spam bugs, support bugs, etc. These bugs are usually directed to either SUMO or AMO to talk to those who can properly assist.
  2. A real Firefox Bug. These are then split down further.
  • A bug that is already reported, is on a developer’s radar, etc. These bugs are typically resolved relatively quickly. Either as DUPE, FIXED, etc.
  • A bug that has not been reported before, or is not affecting a developer’s “pet project”. These bugs are typically ignored and shoved aside. They may be fixed in later years when the component they are filed against is rewritten, or some developer stumbles against the bug later on and fixes it. These bugs may be edge-case bugs, or really minor issues, but they are still bugs.

Now I realize developers have to have priorities. P1, P2, etc. I’m not expecting every bug to be treated the same. not all bugs were created equals, and there is no way to fix every bug within the first week it is filed. And fixing bugs isn’t very glamorous work. It looks a lot better with a new release to say “Redesigned component X with New Features A, B and C” compared to “Fixed 20 bugs in print preview”.

Scenario

But which makes a greater impact on our users? Ensuring that our users have a solid product with minimal bugs, or giving them all the bling that “the Other Browser” has. I love new Features. I think all the hard work in Firefox 4 like the redesigned Addons Manager, Theme, etc are great and help make a competitive product. But, running through triage I see so many bugs marked as NEW, and then never looked at again (As I commented on in another post). This is disheartening to users. Imagine the scenario:

John is IT tech at a local community bank. He finally convinced the IT Dept. Head to let him run a test run of Firefox on all the bank’s computers. Everything seems to be running great. Until, a few days later, John starts to notice complaints that their proprietary web-based plugin site does not allow the use of navigation keys when the plugin form has focus. This is a major issue for the bank because the tellers are trained to only use the keyboard for sake of speed. Some terminals don’t even have mice, meaning they essentially become trapped once focus is captured by the plugin. With no easy answer to the issue and no patch forthcoming in over 10 years, John is forced to switch to a browser that doesn’t have the same issue. All the great features, speed, and functionality came to nothing when a relatively minor bug caused a major breakdown in the bank’s operations.

All of this could have been avoided if a developer had taken notice of the bug and it had been addressed years before.

Solutions?

Now as someone I respect very much in Mozilla has said “If all bugs were security bugs, they would be fixed very quickly”. And major regressions, and common bugs are frequently fixed very quickly (ie. within a month or so). However, the sad reality is that many bugs reported by end-users go ignored for a very long time. If it is not acceptable for a company making a physical product to have a 2% failure rate, how can we ship a product with over 7000 bugs in NEW, ASSIGNED and REOPENED? I know it is impossible to reduce that number to even 1,000. But, I think we should be able to cut those NEW bugs at least. Maybe what is needed is a developer (or three) who is assigned for a while to go through, reproduce old NEW bugs and fix them. I think that the Papercuts push was a great idea, the unfortunately kinda flopped. Maybe a push like this on every major release of Firefox would help, so long as the follow through was there. Ideas?

Advertisements