[Libreoffice-qa] Bug Triage Process Update

Petr Mladek pmladek at suse.cz
Tue Nov 8 08:52:09 PST 2011

Hi Rainer, others,

I propose few changes to http://wiki.documentfoundation.org/BugTriage,
see below. I think that the page is slightly outdated. Also I suggest
few changes in the workflow. You are the experts, I would like to know
your opinion :-)

1. Duplicated steps on the main QA wiki page:

I have removed the following from http://wiki.documentfoundation.org/QA:

--- cut ---
* Simply try to confirm one of the UNCONFIRMED LibreOffice Bug reports.
  It is really easy, simply:
              * Search for a bug from the list where you might have
              * Try to reproduce the problem following the step by step
              * leave a comment concerning your results in the bug
                report (You have to register if you do not have an
--- cut ---

It looked like the step 3 from the Bug Triage process.

Is that OK that I removed it or is it something different?


Do we really want to triage bugs in the state NEW or ASSIGNED?

IMHO, these states means that the bug is confirmed and ready for

I suggest to query only UNCONFIRMED and maybe REOPENED bugs.
We might clean up any mess in the other and older bugs in the regular
bug hunting sessions.

3. Query last two days:

Do we want to query only last two days?
Are all bugs triaged so quickly?

I agree that we should prioritize recent bugs but we lose the older bugs
too quickly this way.

I suggest to prolong it to 1-2 weeks or do more queries. Well, we might
check the old bugs in the regular bug hunting sessions. Anyway, I still
thing that two days are not enough :-)

4. UNCONFIRMED bugs handling:

Do we still need to put CONFIRMED to the Whiteboard?

IMHO, the bug is confirmed when the status is not UNCONFIRMED.

I suggest to remove the note about updating Whiteboard :-)

5. NEEDINFO handling:

I remember the discussion on the devel list, see

I suggest to use the NEEDINFO status already now. If you need
information, you should ask the info provider by name in the comment and
set the NEEDINFO status. IMHO, this is what people will do intuitively
if they do not read any documentation ;-)

Alternatively, we still could mention the infoprovider in the
Whiteboard. Though, people will forget it anyway.

6. Assigning bugs:

Unfortunately, I have missed the discussion 

I am not sure if the is a good idea to assign all bugs to the few people
on the http://wiki.documentfoundation.org/FindTheExpert page.

It is clear that one developer can't fix 500 bugs anytime soon. Most of
the bugs will stay there forever.

IMHO, we have the following possibilities (some of them suggested in the
old discussion):

1. set up mailing list for every group of expertise.

   This solution looks reasonable. I am only afraid that it still will
   be hard for the few developers to sort the many bugs.

2. assign the bug for selected developer for the given expertise and
   suggest other interested people to watch his bugs by the bugzilla

   I do not like this solution. If I were the poor assignee, it would
   destroy my workflow with bugzilla. I check mails from bugzilla
   and will not be able to reasonably handle the flood.

3. take the responsibility and prioritize the bug. Add most critical
   and urgent bugs to the most annoying bugs and add experts into CC.
   Put experts into CC for other critical bugs. Leave it unassigned for
   normal bugs. Just make sure that the category is correct.

   Developer will assign the bug to his name when he wants to work on
   it in the future.

   Developer should set the status to ASSIGNED when he really start
   working on the bug.

IMHO, none of the solutions is ideal. I prefer the third solution.

Best Regards,

More information about the Libreoffice-qa mailing list