Why not triaging confirmed bugs instead of new ones?

[Alberto Salvia Novella]

Omer Akram:
> One thing we need to know is that not everyone is willing to report each
> and every bug they see.

MIXED TWO DIFFERENT TOPICS

I think I have mixed two different topics:

  1. Confirming bugs to belong to the tester role, and not to the 
triager one.

  2. Confirming bugs by reading reports one by one to add little value 
and much more hard work compared to just testing the software by hand, 
reporting found bugs and see if Launchpad says someone reported the 
error before you.


BETTER MOVING THROUGH A LINE THAN AN SPAGHETTI

What I see is this:

- Mixing confirming and triaging overly complicates bug management, 
since you'll be forced to test most new bugs in their specific release. 
So you will have to be constantly loading virtual disk images or, most 
probable, just omitting triaging bugs; accumulating them on a pile.

- So, if you want to confirm bugs, it will be better to load one virtual 
disk image and test it; instead of changing from one image to other 
while performing a complex process as triaging is at the same time.

- While people can dislike reporting bugs, they usually confirm relevant 
ones.

- The main reason why people dislike reporting bugs is because they 
think no one will look at them most of the time, and the real reason for 
no one looking at them is people confirming reports one by one instead 
of testing the software by hand and telling Launchpad what they found.

- Each Ubuntu release is published with many relevant confirmed bugs 
being unfixed, because triagers are spending their time in bugs that can 
be important, but not in bugs that are already known to be.

- What we will want, specially having this amount of reports, is to make 
the most of our triaging time: to make the work that will impact the 
quality of Ubuntu the most, instead of being looking through noise most 
of the time.

- Paying the prize of omitting a few important bugs is worth having the 
most disruptive ones triaged fast, months in advance the final release 
is hit, so developers have time to fix them in advance out of Stable 
Release Updates.


PRODUCTIVITY IS DISTINGUISHING IMPORTANT FROM THE MOST IMPORTANT

In fact this is what several philosophies suggest as the most important 
thing: to forget about details, although they can be somehow important, 
in order to deal with the most important first:

  - Unix Philosophy: "This is the Unix philosophy: Write programs that 
do one thing and do it well".

  - Unix Rule of Robustness: "Robustness is the child of simplicity. 
Developers should design robust programs by designing for transparency 
and discoverability, because code that is easy to understand is easier 
to stress test for unexpected conditions that may not be foreseeable in 
complex programs".

  - Richard P. Gabriel: "Worse is better: simplicity of both the 
interface and the implementation are more important than any other 
attributes of the system—including correctness, consistency, and 
completeness".

  - Pareto Rule: "The 80% of value is brought by the 20% of work".

  - Goethe: "Important things should never be at the mercy of less 
important ones".

  - Brian Tracy: "There isn't enough time to do everything, but there's 
always enough time to do the most important things".

  - Brian Tracy: "You should never deal with important things while you 
have a big frog staring in front of you".

  - Taiichi Ohno: “All we are doing is looking at the time line, from 
the moment the customer gives us an order to the point when we collect 
the cash. And we are reducing the time line by reducing the non-value 
adding wastes”.

- Taiichi Ohno: “The only place that work and motion are the same thing 
is the zoo where people pay to see the animals move around”.

- Taiichi Ohno: “Why not make the work easier and more interesting so 
that people do not have to sweat?  The Toyota style is not to create 
results by working hard. It is a system that says there is no limit to 
people’s creativity.  People don’t go to Toyota to ‘work’ they go there 
to ‘think’”.

- Eliyahu M. Goldratt: “An hour saved at the non-bottleneck is a mirage”.

- Eliyahu M. Goldratt: “I say an hour lost at a bottleneck is an hour 
out of the entire system. I say an hour saved at a non-bottleneck is 
worthless. Bottlenecks govern both throughput and inventory”.

- KISS Rule: "Keep It Simple Stupid" (if it is complex it is not smart, 
no matter what is thought).


I HAVE SEEN SORCERY

So do you feel like fighting giants when triaging?

Because I have seen to cut down a process from 40 minutes to 1 second, 
building 15 trucks in the time of 1, and reducing a list of 300.000 work 
items to three lists of 8.

And the used method always has been this: forget about the 80% of work 
and use it to deal with many 20%s as possible.


Regards.