Re: [QA] Quality of bug reports and QA in bugzilla
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
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 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
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
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
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 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
-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 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
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 pgpQBNEIIuMYb.pgp Description: PGP signature
Re: [QA] Quality of bug reports and QA in bugzilla
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
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
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
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
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
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 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
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 > > 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
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
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
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 >5003 2010 >5001 2011 >5007 2012 20482 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)
Re: [QA] Quality of bug reports and QA in bugzilla
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 pgpNlN42CsZzP.pgp Description: PGP signature
Re: [QA] Quality of bug reports and QA in bugzilla
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
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
2012/9/19 O.Felka : > 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 aliu...@gmail.com
Re: [QA] Quality of bug reports and QA in bugzilla
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
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
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
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 pgpx3uWEv5Zaq.pgp Description: PGP signature
Re: [QA] Quality of bug reports and QA in bugzilla
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 signature.asc Description: OpenPGP digital signature
Re: [QA] Quality of bug reports and QA in bugzilla
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 >5003 > 2010 >5001 > 2011 >5007 > 2012 20482 > > 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
[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 >5003 2010 >5001 2011 >5007 2012 20482 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