[Libreoffice-qa] Bugs prioritization - missing pieces
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 ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org 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/
Re: [Libreoffice-qa] Bugs prioritization - missing pieces
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. 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 can be a very good base (although believe it's a little too rich in detail). I suggest something like Use: * Blocker if it's definitively Critical and additionally * Critical if it's criteria for Major is fulfilled and additionally and so on. I can put it into the line, but if someone else is interested, he should start to improve chapter on Bug Report Details. Best regards ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org 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/
Re: [Libreoffice-qa] Bugs prioritization - missing pieces
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: Libreoffice-qa@lists.freedesktop.org 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/
Re: [Libreoffice-qa] Bugs prioritization - missing pieces
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: Libreoffice-qa@lists.freedesktop.org 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/
Re: [Libreoffice-qa] Bugs prioritization - missing pieces
Joel Madero schrieb: Ultimately I think the whole QA wiki needs redone but we can maybe start with the triaging section. Hi Joel, I think so, too. That has been growing with the project with lots of ad hoc kludge (most created by me) has been added. That all is very muddled. Writing manuals is none of my favorite jobs, so I will not contribute very much contents. Best regards Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org 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/
