[Libreoffice-qa] Bugs prioritization - missing pieces

[Joel Madero]

I will have to address the full thread in a few hours when I can sit 
down and think a bit about this but a couple points:

a) I feel strongly that we should be actively aiming at making the 
triaging a more "important" aspect of development and agree with Petr 
that we should use priority and severity now that our team has grown (a 
little?) and especially since now it seems like we are more aggressive 
at triaging - going to sent out an update on UNCONFIRMED in a bit.

b) As for the components, after UNCONFIRMED I intend on making this our 
"next project" if Rainer is okay with this. This would be going through 
all the bugs currently marked as just LibreOffice and UNCONFIRMED and 
setting their components and then setting their priority.

c) I will upload the draw file for the flowchart so anyone can edit it 
and make other examples, I see that Rainer doesn't particularly love 
parts of it -- maybe he'd be willing to edit it a bit and make a second 
example?

d) The QA wiki, and in particular the triaging/components section really 
seems bad to me. Rainer, if you have time I'd like to discuss with you 
(and implement) corrections to the triaging section. I think it's so 
scattered and disconnected that it makes it incredibly hard to do things 
right. For instance the flowchart that I added is on this "severity" 
page that I can't even find half of the time, I always have to dig 
around past emails to find out where my own flowchart is because it's 
not included in the bug triaging page where it belongs.

Ultimately I think the whole QA wiki needs redone but we can maybe start 
with the triaging section.

Lastly, I've been out of the loop for about a week struggling with 
computer issues so it's going to take me a couple days to get back into 
it (still haven't computer issues, might have to change distros which is 
always "fun"...) so my ability to use LibreOffice is still a bit limited 
with now.

As always I am excited with the progress, suggestions, comments and 
complaints about LibreOffice as I feel like all of them will lead to a 
better product.

I will read the full thread in a couple hours and send a second email 
out if necessary.

Best Regards,
Joel

On 08/20/2012 05:59 AM, Petr Mladek wrote:
> Rainer Bielefeld píše v Po 20. 08. 2012 v 13:21 +0200:
>> Petr Mladek schrieb:
>>
>>> I think that we really should set severity and priority.
>>
>> Hi Petr,
>>
>> a while ago we decided that we should not invest too much time into this
>> because of numerous abuse of these flags.
> It was during times when we had 2 or three people doing bug triage. The
> list of non-triaged bugs was growing.
>
> I think that we are in a different position now. We have more very
> active triagers. They have ambitions to end up with zero non-triaged
> bugs. They put a lot of energy into reproducing bugs, getting
> backtraces, ... Though, bugzilla is still a kind of swamp and only the
> very critical bugs are highlighted for developers. IMHO, it is a shame.
> I think that full prioritization would be a big win. It would allow to
> get rid of the schizophrenic MAB, moving bugs between MABs, ... Of
> course, it makes only sense if we have resources to triage all bugs. I
> believe that we have now.
>
>>   But indeed, I use Priority for
>> my workflow (without trusting selected prio too much), and so we should
>> extend rare info on
>> <https://wiki.documentfoundation.org/BugReport_Details#Severity> to get
>> a useful guide. I think Joels chart
> https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
>>   can be a very good base (although
>> believe it's a little too rich in detail).
> I think that we should add more examples. Do you miss anything else?
>
>
>> I suggest something like
>>
>> Use:
>> * Blocker if it's definitively "Critical" and
>>     additionally ....
>> * Critical if it's criteria for "Major" is fulfilled and
>>     additionally ....
> Hmm, this is reverted logic against the flowchart. I am not sure how to
> convert it.
>
> Note that the flowchart describes also priorities => more complex task.
> It is still pretty readable and understandable. I am not sure if we
> could achieve this by itemized list.
>
> Well, it is possible that you do not like the system described in the
> chart. You might want to do the decision another way. Let's discuss it.
>
>
>> I can put it into the line, but if someone else is interested, he should
>> start to improve chapter on Bug Report Details.
> I would prefer to improve the Joel's chart. It is sexy and easier to
> understand than a long text.
>
> Best Regards,
> Petr
>