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: [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/
