Hi, I agree with Joren. I know that the earlier you solve a bug (in master instead of in 3.6 versions for example), the better/more simple it is (no need to cherry-pick, etc.). But, for some people the highest priority may be: - unconfirmed regressions (because it's very frustrating to have been advised to use a newer version, see a lot of improvements, bugs solved, etc. in this new one and stumble on a regression bug) - unconfirmed blockers (of course I talk about "real" blocker according to https://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Definition) - unconfirmed for Base/Writer/... according what you use daily/prefer/know better... - very old unconfirmed (because the reporter may think nobody takes care of his/her bug and probably won't submit others if he/she finds new ones) - ... In brief, it's a matter of personal opinion (which can change with the time)
I know that you just meant suggestions but it could be relevant to let anyone triaging the bug he/she wants ; it's more incitative and you're more "efficient" when you work on something you decided. That's why I would remove this part. For the rest, I didn't know this page and think it's is a good and useful following to other pages like these: https://wiki.documentfoundation.org/BugReport https://wiki.documentfoundation.org/QA/BSA/BugReport_Details to bring people go a step further in QA. Julien -- View this message in context: http://nabble.documentfoundation.org/Suggested-Prioritization-For-Triaging-tp4058346p4058416.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice