[Libreoffice] minutes of ESC call ...

[Bjoern Michaelsen]

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