incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Herbert Duerr <>
Subject Re: [QA] Quality of bug reports and QA in bugzilla
Date Thu, 20 Sep 2012 15:55:34 GMT
On 20.09.2012 22:20, Herbert Duerr wrote:
> On 20.09.2012 16:54, TJ Frazier wrote:
>> On 9/20/2012 00:12, Herbert Duerr wrote:
>>> On 19.09.2012 20:34, Ariel Constenla-Haile wrote:
>>>> On Wed, Sep 19, 2012 at 02:24:11PM +0200, Oliver Brinzing wrote:
>>>>> Hi Regina,
>>>>>> Your own new issue should be UNCONFIRMED. Someone else should confirm
>>>>>> your issue, if possible on a different operating system.
>>>>> i am pretty sure that i did not set the "confirmed" status when
>>>>> submitting a new issue,
>>>>> default status is "confirmed" - and you have to select "Show Advanced
>>>>> Fields"
>>>>> to see the listbox ... this seems to be the root cause of the problem
>>>>> ...
>>>> I agree with Oliver, the default status should be set to UNCONFIRMED
>>>> even if the reporter has canconfirm privileges. IMHO "confirmed" means
>>>> "confirmed by some else".
>>> Seeing so much consensus I'm confident that we'll reach "lazy consensus"
>>> by next monday (2012/9/19 + 72h) and I volunteer to change the behavior
>>> then.
>>> So please speak up now if you disagree with the opinion that the extra
>>> step to the "confirmed" status is an idea that does benefit the quality
>>> of our project.
>>> Herbert
>> +1
>> Just for the record, is this as simple as removing the check-mark from
>> one entry in BZ > Administration > Bug Status Workflow ?
>  From a testing standpoint having the policy that a "confirmed" status
> means that another member has reproduced the problem (eventually on
> another platform) means more testing effort by some factor. That may
> have a positive or a negative effect on the quality.
> Another possibility could be that a reporter with can-confirm karma
> feels confident enough can set the status to confirmed himself/herself.
> Having to do an extra step could be sufficient for our goals.
> Coming back to your question: Yes, from the admin standpoint the
> requested change is as simple as switching a bit. An eventual
> multiplication of the testing effort is worth some consideration though
> and "just switching bits because it is easy" shouldn't be done without
> having reached some consensus on this topic.

For completeness I'd also like to mention that there is AFAIK no way in 
Bugzilla as of 4.2 to set the default status of new issues to 
UNCONFIRMED for members with can-confirm karma.

If I interpret the contributions to the discussion right there already 
were two opinions disapproving of switching the qa-process to fully 
independent confirmation. Having an issue reporter take an extra step 
for confirming an issue could be a reasonable compromise.

On the question of mis-confirmed issues maybe we should also have a new 
discussion on who should get canconfirm-karma. The spectrum of options 
is wide. The current practice is that some bz-admins give full bits to 
everyone who asks for them and other bz-admins elevate the bits only for 
contributors who showed reasonable experience and merit in that topic 
(see the 2012/06 ooo-dev thread for details). Maybe we could even employ 
the same process used for committer-rights such as discussing and voting 
on each candidate in the private lists, but that option is IMHO on the 
way-too-heavy side.


View raw message