Hi, On Tue, Dec 23, 2014 at 10:31:35PM +0100, Cor Nouws wrote: > One thing that may be handled too: when confirming also check if it > worked before (regression or not) and such.
True. In the end a fully triaged (aka a bug that a QA guys can do nothing more about and that only can be moved forward by a developer) is either: 1/ a regression, which has been bibisected 2/ a non-regression, missing feature (enhancement) 3/ a non-regression, bug introduced with new feature from the start We have proper tags to identify the first two of the above, but nothing to tag the last group. If we _had_ a whiteboard status for number three too, we could query for confirmed bugs that are: - not a bibisected regression - not an enhancement request - not marked as a bug introduced with a new feature from the start and have a list of confirmed bugs that QA can still help about. As such Id suggest maybe a whiteboard status "newfeaturebug" for this. Opinions? Best, Bjoern P.S.: Note there is some wiggle room in distingushing group 2/ and 3/. IMHO if a developer of a feature says its group 2/ (aka that it was not in the planned scope of the new feature) that should be accepted in general (and possibly also documented that way). _______________________________________________ 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/
