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


_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [email protected]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Reply via email to