Re: [Libreoffice-qa] minutes of ESC call ...

Le 20/09/2016 à 11:18, Bjoern Michaelsen a écrit :

If I might interject my ha'pence-worth into the discussion :


> NEW _should_ mean triaged for all matters. That it is not called the more

This is where, in my experience with LO-QA, developer expectations and
QA/user actions do not always coincide. Some developers ask for full
backtrace with symbols before even deigning to sniff at a bug report. It
would be useful methinks to have some kind of consensus here, at least
from the developers, with a view to how that would impact the number of
bug reports that would then necessarily remain in the UNCONFIRMED
setting if we were to take such a demanding point of view.






> NEW          | devs                      | fix the bug
> ASSIGNED     | whoever is in assigned to | fix the bug [1]
> REOPENED     | devs                      | fix the bug [2]

I would take issue with the premise that only a dev can re-open the bug
report, simply because this almost never happens today.

At present, BZ allows normal bug reporters to re-open a report, which, I
would agree, probably isn't the ideal situation, however, if the
reporter is the only one to test the fix other than the developer and it
doesn't solve the issue as initially reported then what else is that
person supposed to do ? In quite a few instances, QA is simply not
around or unaware to be even able to test the fix and provide separate
confirmation/denial that the fix has solved the issue (unless they are
one and the same person). Such a narrow approach also relies on the fact
that the bug report is based on a specific code path fix, whereas the
problematic behaviour reported might actually be dependent on several
code execution sequences that form the whole behaviour.


An example (since it gives an idea of the mismatch in expectations) is
the extensions manager under OSX, where users have not been able to add
or update their extensions for quite a while now. The users expect to be
able to just update their existing extensions, irrespective of whether
it be by double-clicking on an OXT, or using the built-in dialog in the
manager. The fact that only one of these has been fixed is irrelevant to
them, in their eyes, "it still doesn't work" as all the other
possibilities are denied them. The fix is at best "partial".

From a developer point of view, the above situation involves several
code execution paths, and the solution is to address each one
independently. However, that is clearly not how a user understands the
situation. How would one then set such a bug ? Is it fixed, or
unconfirmed, or new, or re-opened or needinfo ? I can understand that
fixing the behaviour of the Add button is not the same as fixing the
behaviour of the Update button, but we need then to be able to convey
this to our users. I get the feeling that here we will end up with a
"you can't fool all of the people half of the time situation" with an
additional layer of fog thrown in to confuse the issue of communication
to the public, which can only serve to be detrimental long term.


Alex