Rainer Bielefeld píše v Po 18. 06. 2012 v 13:21 +0200: > Joel Madero schrieb: > > I brainstormed a bit today and I came up with this flowchart. > > > Hi Joel, > > great to see that all in a chart, your conclusions and definitions seem > plausible. > > But the chart also shows the limitations of that concept: It's really > sophisticated, and no developer will sit at his's desk to decide whether > he should fix a Bug with Severity=major and Priority=normal before or > after a bug with Severity=normal and Priority=high ;-)
You are right, developers will not strictly follow the severity and priority. On the other hand, they care of the usability of the application. They are actively working on the most annoying bugs. They prioritize bugs themselves, so why not help them. Note that MAB is only a workaround because all the other bugs are not prioritized. I think that it is hard job to prioritize all bugs. It will cause some troubles because different people might have different opinions. Though, I think that we should try it. > But as you stated, such a chart can give some orientation, and so I > think it should be shown in the Wiki. Not on one of the current existing > Pages like BugTriage or similar, but on a page where should gather > detailed background information what would blow up those pages too much, > but nevertheless are interesting or important to know for all who want > to gain more knowledge concerning th bugfixing, QA or whatever else process. You are right that we need to keep the bugtriage page easy to do not scare people. It would make sense to describe the prioritization on extra page and just link it from the BugTriage page. BTW: Recently someone said that the Bugtriage page was not easy to understand (state CONFIRMED). I think that some people might prefer the graphics flow chart over the text. It would be nice to have similar flow chart also for the overall bugtriage process :-) > The question is whether the Priority entry is evaluated by anyone, IMHO > most here see that as a personal statement (of reporter?) concerning > importance of the bug - and ignore it. Good question. My opinion is: + severity defines how much a bug affect the functionality + priority defines order in which it should be fixed It means that, some feature might have higher priority because of marketing reasons. Also some less severe bug might have higher priority because it affects many users. Hmm, when I think about it, I would propose another prioritization: 1. Define severity by symptoms. + this is well handled in the flow chart. + alternative proposal is at at http://wiki.documentfoundation.org/BugReport_Details#Severity is reasonable. + I think that they both describe the same things different way. I do not have any strong opinion what formulation is easier to understand. We would need feedback from more people ;-) 2. Define priority more clever way: + the default priority should basically follow the severity; it means that critical bugs should have high priority, ... + the number of affected users and visibility should shift it higher or lower, though + it is already somehow handled in the flowchart. Well, I would, allow to skip even more levels. For example, typo in the main menu is minor bug but it might have even highest priority. Such bug in final release would look amateurish and would bring bad feeling from users. Hmm, I am not sure how to effectively describe it in the flowchart. + with this logic, the bugs with the high and highest priority should be mentioned in MAB. + anyway, developers should have the final word about priorities (for assigned bugs); they might want to organize their daily work by it 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/