You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Regina Henschel <rb...@t-online.de> on 2012/09/19 13:47:19 UTC
[QA] Quality of bug reports and QA in bugzilla
Hi all,
I notice a quality problem in bugzilla. Far too many issues are in
status CONFIRMED which should not be there.
For comparing do a search with:
Bug created 'greater or equal' 2008-09-18 and 'less than' 2009-09-18
and status changed from CONFIRMED
and resolution is any of DUPLICATE, INVALID
and same for the next years.
And then do the same with status changed from UNCONFIRMED
You get
Year from UNCONFIRMED from CONFIRMED
2009 >500 3
2010 >500 1
2011 >500 7
2012 204 82
Please, all those who have 'can confirm' rights in bugzilla, be more
careful.
- Your own new issue should be UNCONFIRMED. Someone else should confirm
your issue, if possible on a different operating system.
- Include duplicates in your search. You might not use the same words as
the older active issue, but your words are likely used in already
existing duplicates and those lead you to the active, already existing
issue.
- Make sure it is really a bug, and not only some settings or handling
you miss.
There are additional problems:
- Operating systems are set to "all" although submitter has only used 1
system.
- It is not clear, whether a problem occurs only with a special existing
document or can be seen with new documents.
- It is not clear whether the problem is new in our AOO or is inherited
from OOo.
- For import/export it is not clear, whether the different formats allow
a correct mapping, or a mapping is not possible because of missing features.
To be clear, this is not about bug reports from users or persons, that
are not familiar with the special problem, but about issues, which were
set to CONFIRMED by someone. And from that person I expect, that he/she
cares for such things.
Kind regards
Regina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Herbert Duerr <hd...@apache.org>.
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.
Herbert
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Herbert Duerr <hd...@apache.org>.
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.
Herbert
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by TJ Frazier <tj...@cfl.rr.com>.
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 ?
/tj/
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Yong Lin Ma <ma...@apache.org>.
Sure. This is not to blame anyone. We are all here to contribute.
We all can learn and grow from this. On the other hand, it proved
again that expertise is needed to open high quality issues.
On Thu, Sep 20, 2012 at 10:27 PM, Regina Henschel
<rb...@t-online.de> wrote:
> Hi,
>
> Yong Lin Ma schrieb:
>
>> -1.
>>
>> Herbert,
>> I would like to save you the effort to make the change, even if it
>> won't cost much.
>>
>> The key thing here is we should be careful and avoid opening duplicate
>> or invalid issues as many as we can.
>>
>> I would like to see some concrete examples, especially invalid issues.
>> And see if this is pervasive for all the reporters who have confirm
>> right.
>
>
> I will not blame single reporters here, please look yourself.
>
> You can search this way:
> Switch to "Advanced Search"
> Near the bottom of the page expand "Custom Search"
> From the first drop down list choose "Resolution", from the second list
> "changed to", and in the third field write INVALID, or write DUPLICATE or
> -if you want both- list them as INVALID,DUPLICATE.
>
> To constrain your search to a specific period, for example issues since
> April, use a second row. From first drop down list choose "Creation date",
> from second list "is greater than or equal to", and in the third field write
> a date in ISO form, for example "2012-04-01".
>
> Search
>
> If the reporter is not shown in the bug list, scroll to the end of the bug
> list and click on "Change Columns". Move "Reporter" from the left list to
> the right list.
>
> Kind regards
> Regina
>
>
>
>
>
--
Regards
Yong Lin Ma
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Regina Henschel <rb...@t-online.de>.
Hi,
Yong Lin Ma schrieb:
> -1.
>
> Herbert,
> I would like to save you the effort to make the change, even if it
> won't cost much.
>
> The key thing here is we should be careful and avoid opening duplicate
> or invalid issues as many as we can.
>
> I would like to see some concrete examples, especially invalid issues.
> And see if this is pervasive for all the reporters who have confirm
> right.
I will not blame single reporters here, please look yourself.
You can search this way:
Switch to "Advanced Search"
Near the bottom of the page expand "Custom Search"
From the first drop down list choose "Resolution", from the second list
"changed to", and in the third field write INVALID, or write DUPLICATE
or -if you want both- list them as INVALID,DUPLICATE.
To constrain your search to a specific period, for example issues since
April, use a second row. From first drop down list choose "Creation
date", from second list "is greater than or equal to", and in the third
field write a date in ISO form, for example "2012-04-01".
Search
If the reporter is not shown in the bug list, scroll to the end of the
bug list and click on "Change Columns". Move "Reporter" from the left
list to the right list.
Kind regards
Regina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by "O.Felka" <ol...@gmx.de>.
Mee too:
-1
Regards,
Olaf
Am 20.09.2012 15:55, schrieb Yong Lin Ma:
> -1.
>
> Herbert,
> I would like to save you the effort to make the change, even if it
> won't cost much.
>
> The key thing here is we should be careful and avoid opening duplicate
> or invalid issues as many as we can.
>
> I would like to see some concrete examples, especially invalid issues.
> And see if this is pervasive for all the reporters who have confirm
> right.
>
>
>
>
>
> On Thu, Sep 20, 2012 at 12:12 PM, Herbert Duerr <hd...@apache.org> 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
>
>
>
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Yong Lin Ma <ma...@apache.org>.
-1.
Herbert,
I would like to save you the effort to make the change, even if it
won't cost much.
The key thing here is we should be careful and avoid opening duplicate
or invalid issues as many as we can.
I would like to see some concrete examples, especially invalid issues.
And see if this is pervasive for all the reporters who have confirm
right.
On Thu, Sep 20, 2012 at 12:12 PM, Herbert Duerr <hd...@apache.org> 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
--
Regards
Yong Lin Ma
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Herbert Duerr <hd...@apache.org>.
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
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Andrea Pescetti <pe...@apache.org>.
Andrew Douglas Pitonyak wrote:
> if an unfiled bug is reported to me and I confirm it independently
> (based on how it was reported to me), may I set it directly to confirmed?
This is what I do most of the times and I would say it's fine: after
all, the bug at that point is confirmed by two independent sources (the
person who reported it to you, or on other channels than Bugzilla, and
yourself).
Regards,
Andrea.
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Wed, Sep 19, 2012 at 06:22:29PM -0400, Andrew Douglas Pitonyak wrote:
> On 09/19/2012 08:34 AM, 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".
> >
> >
> >Regards
> if an unfiled bug is reported to me and I confirm it independently
> (based on how it was reported to me), may I set it directly to
> confirmed?
Yes, and this is what I usually do for bugs that I find. Submitting your
issue and confirming it, is different from it being confirmed just
because it's the default bugzilla setting. Of course, this can be
considered an overhead, though it's simple a second step after pressing
submit (that IMHO ensure carefulness).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Andrew Douglas Pitonyak <an...@pitonyak.org>.
On 09/19/2012 08:34 AM, 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".
>
>
> Regards
if an unfiled bug is reported to me and I confirm it independently
(based on how it was reported to me), may I set it directly to confirmed?
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Regina Henschel <rb...@t-online.de>.
Hi Olaf,
O.Felka schrieb:
> Am 19.09.2012 14:34, schrieb Ariel Constenla-Haile:
>>>
>>>> Your own new issue should be UNCONFIRMED. Someone else should confirm
>>>> your issue, if possible on a different operating system.
>>>
>
>> 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".
>>
>
> We have a lot of professional QA folks here: They know how to verify
> their findings and issues. That's a lot of overhead if someone has to
> re-test to confirm a well tested bug.
> So we should trust the QA who has 'canconfirm' privileges.
If bug reports were really in a good state, I would not see a problem in
starting in confirmed status. That has worked for a lot of years. But
the problem is, that in recent weeks I have come across many bug
reports, which started in confirmed status but are invalid or duplicate.
Therefor my appeal, to be more careful.
Kind regards
Regina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Zhe Liu <al...@gmail.com>.
2012/9/19 O.Felka <ol...@gmx.de>:
> Am 19.09.2012 14:34, schrieb Ariel Constenla-Haile:
>
>>>
>>>> Your own new issue should be UNCONFIRMED. Someone else should confirm
>>>> your issue, if possible on a different operating system.
>>>
>>>
>
>> 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".
>>
>
> We have a lot of professional QA folks here: They know how to verify their
> findings and issues. That's a lot of overhead if someone has to re-test to
> confirm a well tested bug.
> So we should trust the QA who has 'canconfirm' privileges.
QA can create an unconfirmed issue and then immediately confirm it by
themselves. Of course, it's better to let others confirm. It's not
forced.
>
> Regards,
> Olaf
>
--
Best Regards
>From aliuzhe@gmail.com
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Regina Henschel <rb...@t-online.de>.
Hi,
Ji Yan schrieb:
> I believe default status is "CONFIRMED" or not is not Regina's concern.
Yes. It is about the fact, that people who are not simple users but
involved here in the project produce a lot of duplicate or invalid issues.
To
> reduce "DUPLICATED" defect, it require reporter search BZ carefully to find
> if there is any similar defect opened before, but how to query BZ it
> depends on reporter's knowledge
Searching BZ is difficult. But sometimes it seems to me, they do not
even try to avoid duplicates.
and which keyword he used. We cannot make
> zero DUPLICATED defect, but we do can ask reporter query with more keywords
> in BZ before open a new one. So I think add more common keywords in BZ
> keyword field may help us reduce DUPLICATED defect.
What do you mean with "keyword"? Do you mean the field "Keywords". That
would not help. You need an intuition about the wording, which are used
in bug reports. Those words are then entered in the "Comment" field.
Kind regards
Regina
>
> 2012/9/19 O.Felka <ol...@gmx.de>
>
>>
>> We have a lot of professional QA folks here: They know how to verify
>>>> their findings and issues. That's a lot of overhead if someone has
>>>> to re-test to confirm a well tested bug.
>>>> So we should trust the QA who has 'canconfirm' privileges.
>>>>
>>>
>>> I don't see much overhead; on the contrary, every careful reporter,
>>> after pressing "Submit", surely goes and check if he did fill everything
>>> ok. Leaving the default status to unconfirmed works just like
>>> a reminder to be careful.
>>>
>>
>> A careful submitter will check before he presses the ok button.
>>
>> Regards
>> Olaf
>>
>
>
>
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Ji Yan <ya...@gmail.com>.
I believe default status is "CONFIRMED" or not is not Regina's concern. To
reduce "DUPLICATED" defect, it require reporter search BZ carefully to find
if there is any similar defect opened before, but how to query BZ it
depends on reporter's knowledge and which keyword he used. We cannot make
zero DUPLICATED defect, but we do can ask reporter query with more keywords
in BZ before open a new one. So I think add more common keywords in BZ
keyword field may help us reduce DUPLICATED defect.
2012/9/19 O.Felka <ol...@gmx.de>
>
> We have a lot of professional QA folks here: They know how to verify
>>> their findings and issues. That's a lot of overhead if someone has
>>> to re-test to confirm a well tested bug.
>>> So we should trust the QA who has 'canconfirm' privileges.
>>>
>>
>> I don't see much overhead; on the contrary, every careful reporter,
>> after pressing "Submit", surely goes and check if he did fill everything
>> ok. Leaving the default status to unconfirmed works just like
>> a reminder to be careful.
>>
>
> A careful submitter will check before he presses the ok button.
>
> Regards
> Olaf
>
--
Thanks & Best Regards, Yan Ji
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Mittwoch, 19. September 2012 um 17:10 schrieb O.Felka:
>
> > > We have a lot of professional QA folks here: They know how to verify
> > > their findings and issues. That's a lot of overhead if someone has
> > > to re-test to confirm a well tested bug.
> > > So we should trust the QA who has 'canconfirm' privileges.
> > >
> >
> >
> > I don't see much overhead; on the contrary, every careful reporter,
> > after pressing "Submit", surely goes and check if he did fill everything
> > ok. Leaving the default status to unconfirmed works just like
> > a reminder to be careful.
> >
>
>
> A careful submitter will check before he presses the ok
The overhead is really minimal but will help to get a better default for the less careful submitters ;-)
Juergen
>
> Regards
> Olaf
>
>
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by "O.Felka" <ol...@gmx.de>.
>> We have a lot of professional QA folks here: They know how to verify
>> their findings and issues. That's a lot of overhead if someone has
>> to re-test to confirm a well tested bug.
>> So we should trust the QA who has 'canconfirm' privileges.
>
> I don't see much overhead; on the contrary, every careful reporter,
> after pressing "Submit", surely goes and check if he did fill everything
> ok. Leaving the default status to unconfirmed works just like
> a reminder to be careful.
A careful submitter will check before he presses the ok button.
Regards
Olaf
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Wed, Sep 19, 2012 at 02:52:44PM +0200, O.Felka wrote:
> Am 19.09.2012 14:34, schrieb Ariel Constenla-Haile:
> >>
> >>>Your own new issue should be UNCONFIRMED. Someone else should confirm
> >>>your issue, if possible on a different operating system.
> >>
>
> >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".
> >
>
> We have a lot of professional QA folks here: They know how to verify
> their findings and issues. That's a lot of overhead if someone has
> to re-test to confirm a well tested bug.
> So we should trust the QA who has 'canconfirm' privileges.
I don't see much overhead; on the contrary, every careful reporter,
after pressing "Submit", surely goes and check if he did fill everything
ok. Leaving the default status to unconfirmed works just like
a reminder to be careful.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by "O.Felka" <ol...@gmx.de>.
Am 19.09.2012 14:34, schrieb Ariel Constenla-Haile:
>>
>>> Your own new issue should be UNCONFIRMED. Someone else should confirm
>>> your issue, if possible on a different operating system.
>>
> 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".
>
We have a lot of professional QA folks here: They know how to verify
their findings and issues. That's a lot of overhead if someone has to
re-test to confirm a well tested bug.
So we should trust the QA who has 'canconfirm' privileges.
Regards,
Olaf
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Andrew Douglas Pitonyak <an...@pitonyak.org>.
On 09/19/2012 10:25 AM, Reizinger Zoltán wrote:
>
> I not agree fully.
>
> In lot of cases I submit a bug found by others, submitted on forums,
> checked by me before I submit a new bug.
> In these case the "confirmed" could be the best deafault.
>
> In other cases the "unconfirmed" is the best deafult value, but the
> "confirmed" value, need to be selectable
> to the reporters with "canconfirm rights".
>
> Regards,
> Zoltan
The initial statement is that confirmed should not be the default, which
is different than whether you can (or may) directly set it to confirmed
because of the situation that you just mentioned.
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Reizinger Zoltán <zr...@hdsnet.hu>.
2012.09.19. 14:49 keltezéssel, Oliver-Rainer Wittmann írta:
> Hi,
>
> On 19.09.2012 14:41, Jürgen Schmidt wrote:
>> On 9/19/12 2:34 PM, 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".
>>>
>>
>> I didn't checked it by myself but I agree the default should be
>> unconfirmed.
>>
>
> I checked it.
> With an account with canconfirm privileges "confirmed" is the default
> status.
> I agree that this needs to be changed.
>
I not agree fully.
In lot of cases I submit a bug found by others, submitted on forums,
checked by me before I submit a new bug.
In these case the "confirmed" could be the best deafault.
In other cases the "unconfirmed" is the best deafult value, but the
"confirmed" value, need to be selectable
to the reporters with "canconfirm rights".
Regards,
Zoltan
> Best regards, Oliver.
>
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 19.09.2012 14:41, Jürgen Schmidt wrote:
> On 9/19/12 2:34 PM, 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".
>>
>
> I didn't checked it by myself but I agree the default should be unconfirmed.
>
I checked it.
With an account with canconfirm privileges "confirmed" is the default status.
I agree that this needs to be changed.
Best regards, Oliver.
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 9/19/12 2:34 PM, 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".
>
I didn't checked it by myself but I agree the default should be unconfirmed.
Juergen
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Ariel Constenla-Haile <ar...@apache.org>.
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".
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Oliver Brinzing <Ol...@gmx.de>.
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 ...
Regards
Oliver
GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 9/19/12 1:47 PM, Regina Henschel wrote:
> Hi all,
>
> I notice a quality problem in bugzilla. Far too many issues are in
> status CONFIRMED which should not be there.
>
> For comparing do a search with:
> Bug created 'greater or equal' 2008-09-18 and 'less than' 2009-09-18
> and status changed from CONFIRMED
> and resolution is any of DUPLICATE, INVALID
>
> and same for the next years.
>
> And then do the same with status changed from UNCONFIRMED
>
> You get
> Year from UNCONFIRMED from CONFIRMED
> 2009 >500 3
> 2010 >500 1
> 2011 >500 7
> 2012 204 82
>
> Please, all those who have 'can confirm' rights in bugzilla, be more
> careful.
> - Your own new issue should be UNCONFIRMED. Someone else should confirm
> your issue, if possible on a different operating system.
> - Include duplicates in your search. You might not use the same words as
> the older active issue, but your words are likely used in already
> existing duplicates and those lead you to the active, already existing
> issue.
> - Make sure it is really a bug, and not only some settings or handling
> you miss.
>
> There are additional problems:
> - Operating systems are set to "all" although submitter has only used 1
> system.
> - It is not clear, whether a problem occurs only with a special existing
> document or can be seen with new documents.
> - It is not clear whether the problem is new in our AOO or is inherited
> from OOo.
> - For import/export it is not clear, whether the different formats allow
> a correct mapping, or a mapping is not possible because of missing
> features.
>
> To be clear, this is not about bug reports from users or persons, that
> are not familiar with the special problem, but about issues, which were
> set to CONFIRMED by someone. And from that person I expect, that he/she
> cares for such things.
>
I think this is very useful information and I cc'ed the qa list. Good
bug reports with as much as possible information, detailed descriptions
how to reproduce the problem or even useful bug docs are very important
and helps a lot. Thanks for bringing this up and raising more awareness.
Juergen
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 9/19/12 1:47 PM, Regina Henschel wrote:
> Hi all,
>
> I notice a quality problem in bugzilla. Far too many issues are in
> status CONFIRMED which should not be there.
>
> For comparing do a search with:
> Bug created 'greater or equal' 2008-09-18 and 'less than' 2009-09-18
> and status changed from CONFIRMED
> and resolution is any of DUPLICATE, INVALID
>
> and same for the next years.
>
> And then do the same with status changed from UNCONFIRMED
>
> You get
> Year from UNCONFIRMED from CONFIRMED
> 2009 >500 3
> 2010 >500 1
> 2011 >500 7
> 2012 204 82
>
> Please, all those who have 'can confirm' rights in bugzilla, be more
> careful.
> - Your own new issue should be UNCONFIRMED. Someone else should confirm
> your issue, if possible on a different operating system.
> - Include duplicates in your search. You might not use the same words as
> the older active issue, but your words are likely used in already
> existing duplicates and those lead you to the active, already existing
> issue.
> - Make sure it is really a bug, and not only some settings or handling
> you miss.
>
> There are additional problems:
> - Operating systems are set to "all" although submitter has only used 1
> system.
> - It is not clear, whether a problem occurs only with a special existing
> document or can be seen with new documents.
> - It is not clear whether the problem is new in our AOO or is inherited
> from OOo.
> - For import/export it is not clear, whether the different formats allow
> a correct mapping, or a mapping is not possible because of missing
> features.
>
> To be clear, this is not about bug reports from users or persons, that
> are not familiar with the special problem, but about issues, which were
> set to CONFIRMED by someone. And from that person I expect, that he/she
> cares for such things.
>
I think this is very useful information and I cc'ed the qa list. Good
bug reports with as much as possible information, detailed descriptions
how to reproduce the problem or even useful bug docs are very important
and helps a lot. Thanks for bringing this up and raising more awareness.
Juergen
Re: [QA] Quality of bug reports and QA in bugzilla
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 9/19/2012 07:47, Regina Henschel wrote:
> Hi all,
>
> I notice a quality problem in bugzilla. Far too many issues are in
> status CONFIRMED which should not be there.
>
> For comparing do a search with:
> Bug created 'greater or equal' 2008-09-18 and 'less than' 2009-09-18
> and status changed from CONFIRMED
> and resolution is any of DUPLICATE, INVALID
>
> and same for the next years.
>
> And then do the same with status changed from UNCONFIRMED
>
> You get
> Year from UNCONFIRMED from CONFIRMED
> 2009 >500 3
> 2010 >500 1
> 2011 >500 7
> 2012 204 82
>
> Please, all those who have 'can confirm' rights in bugzilla, be more
> careful.
> - Your own new issue should be UNCONFIRMED. Someone else should confirm
> your issue, if possible on a different operating system.
> - Include duplicates in your search. You might not use the same words as
> the older active issue, but your words are likely used in already
> existing duplicates and those lead you to the active, already existing
> issue.
> - Make sure it is really a bug, and not only some settings or handling
> you miss.
>
> There are additional problems:
> - Operating systems are set to "all" although submitter has only used 1
> system.
> - It is not clear, whether a problem occurs only with a special existing
> document or can be seen with new documents.
> - It is not clear whether the problem is new in our AOO or is inherited
> from OOo.
> - For import/export it is not clear, whether the different formats allow
> a correct mapping, or a mapping is not possible because of missing
> features.
>
> To be clear, this is not about bug reports from users or persons, that
> are not familiar with the special problem, but about issues, which were
> set to CONFIRMED by someone. And from that person I expect, that he/she
> cares for such things.
>
> Kind regards
> Regina
>
I think I see how to prevent an initial CONFIRMED status in BZ. If we
reach consensus, I will do that. (I am in favor.)
/tj/ (BZ admin)