[Libreoffice-qa] bug prioritization: was minutes of ESC call ...

[Petr Mladek]

bfo píše v Čt 29. 11. 2012 v 11:43 -0800:
> Michael Meeks-2 wrote
> > * QA update (Joel)
> > [...]	+ triage backlog has grown
> > 		+ QA team meeting / ideas for fixing that
> 
> Hi!
> Please consider refocusing. Just look at NEW backlog:
> https://bugs.freedesktop.org/reports.cgi?product=LibreOffice&datasets=NEW. 
> It is >3500 NEW bugs.
> Status: NEW Assignee: libreoffice-bugs at lists.freedesktop.org = 3303 bugs 
> ready to take over (for me unassigned bug is a "take me" candidate). Table
> by component: http://tinyurl.com/LO-NEWbyComponent.   
> I think triage backlog is not a problem anymore. If we add hundreds more NEW
> bugs - will it change anything? Improve quality of a product? I see serious
> bugs mismanagement here.  The better solution would be to prioritize those
> existing NEW bugs and show developers which should be fixed first. I am not
> aware that such actions are taking place/are planned anytime soon. 
> Best regards.

I see your pain. I also think that full prioritization makes sense.
There already is a proposal, see
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Anyway, we already do something, see
http://wiki.documentfoundation.org/QA/BugTriage#Set_Status_.26_Prioritize

So, we use 3 levels and some side steps:

1. level: MABs for most critical bugs
2. level: developer in CC for other critical bugs
3. level: valid, reproducible bug with correct Component: marked as
          state NEW for others

The side steps are the keyword "regression" and Whiteboard flags, see
http://wiki.documentfoundation.org/QA/BugTriage#Whiteboard_Status
They help to get attention as well.
         

In each case, the bug triage is still very important because it helps to
find and escalate the critical bugs as they come. Also it helps to clean
up other bugs, so they are prepared for fixing.

If you look at the fixed bugs, we fix also bugs that are not in MAB or
regressions, so there are different ways how developers take them. Any
well prepared bug makes the fix faster, so the limited group of
developers could fix more of them.

I still dream about the full priritization. I like Joel's proposal in
the above mentioned flow chart. It actually incorporates many of your
ideas because it prefers regressions, crashers, data loss.

I think that we only need to get a wider consensus, add more good
examples into the Flowchart and promote it.

Note that prioritization is always a bit subjective. It newer will be
perfect. Anyway, I would be happy if at least 90% of bugs have some
reasonable setting +- one severity and priority level.


>P.S. 
> Increasing NEW stats are discouraging for any potential serious triage
> volunteers.

I am afraid that number of bugs will be always growing if we do not
close some enhancement requests or controversal bugs with WONTFIX or
INVALID.

Note that if we fix all serious problems, people will report problems
such as that an icon is not enough pink or blue :-)

Anyway, the open bugs need not be that bad if these are minors or have
reasonable workarounds. Nobody is perfect.

Thanks a lot for doing the bug triage. I know that it is sometimes very
depressing. But it is really important work. You help a lot!


Best Regards,
Petr