[Libreoffice-qa] Bugs prioritization - missing pieces

Petr Mladek pmladek at suse.cz
Mon Aug 20 03:02:03 PDT 2012


Hi,

I still miss instructions how to set severity, priority, and component
during the bug triage process. I think that we really should do it.

Joel has a great proposal for severity handling at
https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
The components are well described at
http://wiki.documentfoundation.org/BugReport_Details#Components
but neither of them are mentioned at
http://wiki.documentfoundation.org/BugTriage

What is missing to adopt it?


Why this should be important?

There were two long threads:

     + The Document Foundation announces LibreOffice 3.6 with a wealth
       of new features and improvements, see
http://lists.freedesktop.org/archives/libreoffice-qa/2012-August/002246.html
     + Closing NEEDINFO bugs, see
http://lists.freedesktop.org/archives/libreoffice-qa/2012-August/002333.html


Both threads were about bugs that were not being fixed. Both threads
explained that it was not realistic to have software without bugs. Booth
threads asked QA guys to tell developers about well prepared and
critical bugs. Though, I miss enough details. I currently know about
several "workarounds":

    + "MAB - Most Annoying bugs" - it is a mix of "nearly blockers"
      and old bugs that annoyed many users for years; they highligh only
      few bugs.

    + HardHacks - new attempt to find volunteer for bugs that are
      old, complicated, and even MAB stick did not encouraged someone
      to fight with it

    + whiteboards flags: regression, bibisect, ...; useful but how many
      people are aware of them? I see this hidden somewhere
      in http://wiki.documentfoundation.org/BugReport_Details; also
      they are not offered by the bugzilla UI => less intuitive
      and error prone (typo)
  
      In addition, I am afraid of the flag "regression". Most bugs are
      regressions from some point of view and we need to prioritize them
      as well.

   + UNCONFIRMED, NEEDINFO, NEW, REOPEN flags tell if the bug is
     triaged and ready for development; this works quite well but it
     is not enough to find important and well prepared bug in the
     bugzilla swamp


I think that we really should set severity and priority. It will cover
more than the top-50 MABs. It will help to find work for developers that
do not see any bug in MABs in their area of expertize. It will be clear
message to users what we think about the bugs and and what they could
expect.

Also I think that we should make sure that the component is correctly
set. It does not make sense to assign 500 bugs to the 3 Calc experts.
They will solve only the most important ones in the given timeframe. We
get more experts as time is running. The correctly set components help
here.

We should continue to use the whiteboard flags (bibisect, backtrace)
because they help to locate really well prepared bugs that should be
much easier to fix.

Of course, it will take some time until bugzilla is organized. But I see
great progress there. In the meantime, we should continue using MABs,
Hardhack, and "regression" whiteboard item. 

How does that sound?


Best Regards,
Petr



More information about the Libreoffice-qa mailing list