Hi, On Wed, Sep 21, 2016 at 12:24:37AM +0200, Áron Budea wrote: > I'd consider a bug triaged with the following steps also done, which are > rarely > done when the bug is set to NEW: > -check in other OSes, > -check if bug is regression. > > Yes, NEW means a developer can start working on it, but there should be a > status > meaning a bug requires no further QA attention (except bibisecting), so in my > book NEW doesn't mean triaged in itself.
Bug states should support the workflow to get the bug fixed -- not the other way around. OS crosschecking is irrelevant in more than 90% of cases for the work of a dev to start working on it. While regression info is quite helpful, very often it is provided already by the initial report even. Both are not reasons for devs to punt on the issue solely because of this -- thus, because bug states should support workflows and not the other way around, not to have yet-another-state and just have devs assume a crossplatform non-regression by default. > The problem with independent confirmations only is that the status is hardly > different from UNCONFIRMED. Assuming QA tried and couldn't reproduce the > issue, > the bug is likely hard to reproduce, and setting to NEEDINFO won't help, as > the > reporter won't know what else to add, and it's a developer who can determine > what kind of further information is needed, and the steps to acquire it. That might be so, but spending developer ressources on the kinds of obscure bugs that cant be triaged by the projects QA ressources isnt a wise choice either. If users cant properly triage a bug with the help of projects QA ressources and there is no volunteer dev jumping on it on own initiative, there are various L3 support options welcoming to help them out. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice