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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice