Raal wrote > what about to take all bugs on release notes page, create bugzilla query > of bugs which are in status "resolved fixed". During BH session people > will test it and they set status to "verified fixed". In this workflow > you can measure progress and partly avoid duplicate work - when you > refresh query, verified bugs disappear.
That sounds like a good plan. Having a reachable goal and being able to see progress is a good way to motivate people. I would participate in such a session. But maybe it would make sense not to start BH sessions with the first Alpha (because by definition Alpha releases are unstable as was proven with Alpha1 which didn't even run under Windows 8+ ) Doing Alpha, Beta BH sessions before the RC in my opinion is too frequent and doesn't seem to be working. I believe it would make sense to do a 5.2 BH session with RC1 with the objective goal of verifying all bugs reported as fixed on release notes plus bugs specific to version 5.2 (new and/or regressions) reported during alpha and beta stages. Of course the RC1 BH session only makes sense if there is some commitment from TDF/developers to actually work with QA to make a "clean" release. Just my 2 non-dev cents... -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Proposal-for-BH-sessions-organization-tp4175684p4182002.html Sent from the QA mailing list archive at Nabble.com. _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: https://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/
