426161 - Bug triage process failed for an important issue

Status: RESOLVED INVALID

(mozilla.org :: Governance, task)

Description

[Aaron Digulla]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-0.1 Firefox/2.0.0.13

Please have a look at bug 369963. It has the following properties:

1. It's ancient (you can't see that in 369963 but there are related bugs which are much older)
2. It's easy to reproduce
3. It's hard to fix
4. It's a common issue for many users
5. Reports about it are coming in since every major release since 1.5.

For some reason, the bug triage process has failed to give this bug the correct priority to get it fixed *again*.

Please fix the bug triage process in such a way that an important bug like this one can't be moderated down unless the project lead approves.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Aaron Digulla]

For other examples like this one, see: bug 262319 for Thunderbird.

It's always the same story: A bug really hurts users, it's a "simple to fix" issue for users and it hurts a lot, people are angry, developers seem unwilling to fix the issues (I say "seem" since that is my point of view; I don't know what really happens, so I have to resort to how I feel) and it gets skipped again and again and again.

What I envision is something like this: When a bug is elevated to the "must be fixed" state, no single developer should be allowed to moderate it down/postpone it and there must be no way to ship a new release unless the bug is fixed.

Maybe even put the power to stop a new release into the hands of the community. If enough people ask that bug to be fixed via the voting system or a bounty, then don't ship until someone has fixed it.

Comment 2

[Dave Townsend [:mossop]]

This is not a Firefox bug, I'm not really sure it should even be in bugzilla, most likely this should be a discussion had on a newsgroup, but over to the closest matching component I can find.

Comment 3

[Aleksey Nogin]

(In reply to comment #0)

> 1. It's ancient (you can't see that in 369963 but there are related bugs which
> are much older)

Yes, it is very ancient - I have reported it as bug 177175 back in October 2002.

I think the problem is that the developers tend to think "I really do not want to touch this messy ugly known-to-be-very-fragile old code to fix a users' annoyance that I myself is willing to tolerate, I'd rather work on a new exciting feature". Not sure what can be done about it, but there needs to be some mechanisms for making sure "minor, but constant annoyance for lots and lots of users" bugs are fixed in a reasonable amount of time...

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Regression is now 13 months old.  Users will vote with their feet when 
serious regressions appear in major new releases.  

Comment 5

[Aaron Digulla]

(In reply to comment #4)
> Regression is now 13 months old.

What do you mean by "Regression"?

>  Users will vote with their feet when 
> serious regressions appear in major new releases.  

They try but at least with those two bugs, a) I'm not sure they are regressions (but rather oversights of the original implementation) and b) they are not "serious" in the sense that the product becomes completely unusable. They are "just" major annoyances which make users turn their backs on the software (after missing a very important mail for the 3rd time ... or when you have to enter your password six times when you start Firefox ... or when you simply can't use the session saving mechanism). This is everyday stuff and it's broken for years, now.

These are not "bugs" but annoyances. They are voted sky high but the development process still fails to handle them.

Comment 6

[Phil Ringnalda (:philor)]

Sky high is rather relative: any time the first step in your Steps to Reproduce is "Add a master password" you've said "this is a bug which affects a tiny percentage of users."

Personally, I don't know what that percentage is, I am a member of that percentage, and I don't mind having people fix bugs that only affect me, particularly when they *really* affect me, but you have to keep in mind while second-guessing drivers' decisions that one of the things they considered was "does this affect one percent of our users, and thus a million and a quarter people per day, or does it affect one hundredth of a percent of our users?"

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Regression?
I believe the bug you cite has the same root cause as bug 338549 and 
bug 368325, and all started at the same time, for the same reason, 
which was the "fix" for bug 326273. 

Comment 8

[Aaron Digulla]

The question is: How can this be prevented? When I report a bug, I might have an idea (or not) how many users are affected. The same is true for the developer trying to fix the bug: Just looking at the code might give an indication how serious something is (or not).

But this issue here is to figure out how to prevent bugs with the following attributes to be ignored:

1. Many votes
2. Many CCs
3. Many comments
4. Age (in Months)

I think if you get a high figure my adding those three (multiply will not work; one of them might be 0), then this is a bug which ought to be fixed but which probably won't get fixed by watching it. Some further steps need to be taken.

Here is my reasoning:

1. Votes: This is obvious.

2. CCs means that many people watch this bug. They might not care to vote but they still want to see when it is fixed. I feel this as "cheap voting".

3. Comments: A lot of comments mean that there is disagreement. For example, users might see something as a bug but the developers never tire to reject this notion (see the file:-URL bugs). Or they can't agree on a solution.

4. Age: If a bug gets old, it either has to die (WONTFIX or RESOLVED) or it has to be fixed (-> BLOCKER).

In any case, as a project lead, these four simple indicators tell me that this is a bug which needs special attention. Maybe I need to have word with the developer in charge. Maybe I need to assign someone else to the task.

Comment 9

[Gervase Markham [:gerv]]

Aaron: I'm sorry to disappoint you, but we are not going to institute some numerical-scoring method of bug triage. I understand your frustration, but your energies are better directed working with individual developers on bugs that are important to you. 

Our process may not be perfect, but getting bugs you care about fixed is a lot easier than in, say, Microsoft Word.

Gerv