[Libreoffice-qa] Bug Triage: What takes the most time? What slows you down?

classic Classic list List threaded Threaded
5 messages Options
Robinson Tryon Robinson Tryon
Reply | Threaded
Open this post in threaded view
|

[Libreoffice-qa] Bug Triage: What takes the most time? What slows you down?

Hi all,

Bug triage is an important part of our work as the QA Team. As
discussed in the QA Meeting today, our UNCONFIRMED bug count is
creeping upwards again, and I'm interested in improving our efficiency
during bug triage.

Even if your nick is more active than IZBot in the #libreoffice-qa
channel, there are only so many bugs that you can triage in an hour.
I'm interested in hearing what takes the biggest chunk of your time
during bug triage, so we can see if we can simplify and/or reduce the
time/energy that we spend on each bug.


Thanks!
--R


--
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
[hidden email]
802-379-9482 | IRC: colonelqubit on Freenode
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage: What takes the most time? What slows you down?

Hi Robinson,

Robinson Tryon wrote on 01-07-15 15:28:

> I'm interested in hearing what takes the biggest chunk of your time
> during bug triage, so we can see if we can simplify and/or reduce the
> time/energy that we spend on each bug.

Thanks for asking.
I estimate that I look at 5-10 new issues per day and step in on maybe
some 5-10 per week currently.
I pick those that are relatively easy for me, or really interesting.
Often I just try to confirm and comment that.
Also frequently I look in one or more older versions, to find out if it
is a new issue.
For some issues I remember that they are already reported and then I try
to find those.
I look at the summaries, if those are clear enough IMO.
Sometimes I try to find other related issues and bring some clarity.
That definitely is most time consuming.

So the most time I spent, is not so much related to keep the unconfirmed
count low as such, but rather on the rest of the work.
Time saving is if a certain area is nicely cleaned, so that finding
related issues is relatively easy.
Maybe an idea: a button on the page with the issue, that starts a query
with many of the arguments already set, taken from the issue?

Cheers,
Cor

--
Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger http://nl.libreoffice.org
- volunteer http://www.libreoffice.org
- The Document Foundation Membership Committee Member
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Alex Thurgood Alex Thurgood
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage: What takes the most time? What slows you down?

In reply to this post by Robinson Tryon
Le 01/07/2015 15:28, Robinson Tryon a écrit :

Hi Robinson,

> Even if your nick is more active than IZBot in the #libreoffice-qa
> channel, there are only so many bugs that you can triage in an hour.
> I'm interested in hearing what takes the biggest chunk of your time
> during bug triage, so we can see if we can simplify and/or reduce the
> time/energy that we spend on each bug.

Generally, poorly worded initial bug reports. I'm less inclined nowadays
to try and second guess what the user has done (or not done), so tend to
stick them straight to NEEDINFO with questions.

Printing bugs and specific database setups also waste a lot of time.
With printer bugs, if you don't have that printer, very often,
attempting to triage is useless, other than stating that you  can't
reproduce on x,y,z printer which is not the one the user filed the bug
against.

Database bugs are painstaking to reproduce without a sample file
provided by the reporter or else complete instructions on how to set up
their particular scenario, and that only works if one has access to the
particular database server - obviously this is easier with integrated
hsqldb. In a database bug, you need to look at :

server (and version) db  vs. embedded db vs file db;
connector : JDBC / ODBC / native;
table definitions;
query definitions;
report builder version;
relations;
Java version.


I only really look at Mac UNCO and db UNCO.

Mac UNCO has been shown to be dependent on OSX version - there are some
bugs I simply can't confirm because I don't see them on OSX 10.10 and
the bugs are reported against earlier versions.


Alex





_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
jmadero jmadero
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage: What takes the most time? What slows you down?

hmm - I'm not sure what the point of this discussion is as whatever the
problem is, it's not "fixable" per se.

On 07/02/2015 02:11 AM, Alex Thurgood wrote:

> Le 01/07/2015 15:28, Robinson Tryon a écrit :
>
> Hi Robinson,
>
>> Even if your nick is more active than IZBot in the #libreoffice-qa
>> channel, there are only so many bugs that you can triage in an hour.
>> I'm interested in hearing what takes the biggest chunk of your time
>> during bug triage, so we can see if we can simplify and/or reduce the
>> time/energy that we spend on each bug.
> Generally, poorly worded initial bug reports. I'm less inclined nowadays
> to try and second guess what the user has done (or not done), so tend to
> stick them straight to NEEDINFO with questions.
I agree with this 100%. My philosophy has always been "the user has some
responsibility to give us a good report" if they fail to do so, I'm not
going to waste more than 1 minute putting a comment and tossing it in
NEEDINFO.

I also rarely look for dupes and the like as this can be incredibly time
consuming - if I see a bug that I recognize I'll spend a few minutes,
else I just confirm and move on.

That being said, everyone has their own style and talking about it isn't
going to make it faster. The reality is that we just need to keep
increasing our numbers and stop worrying if there is a small spike in
unconfirmed bugs. We've got it under control (the days where we're at
1700 are gone). Sure we see small spikes occasionally but no reason to
philosophize over why...there's a simple explanation, there are
100,000,000 users approximately and less than 100 active triagers so, at
a 1,000,000:1 ratio, we're going to see spikes occasionally.


Best,
Joel
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Terrence Enger Terrence Enger
Reply | Threaded
Open this post in threaded view
|

Re: Bug Triage: What takes the most time? What slows you down?

In reply to this post by Robinson Tryon
On Wed, 2015-07-01 at 09:28 -0400, Robinson Tryon wrote:
> I'm interested in hearing what takes the biggest chunk of your time
> during bug triage, so we can see if we can simplify and/or reduce the
> time/energy that we spend on each bug.

A good chunk of the time--and a disproportionately large part of the
frustration--is checking for potential duplicates.  The hard part, of
course, is imagining the words that an existing report might use to
describe the problem.  An implausibly short list from a bz query or a
tremendously long one are both useless.

If bibisecting shows that a bug is fairly new, a limitation by bug
creation date can usefully restrict the number of potential duplicates
returned.

Still, finding duplicates is the part of the process about which I
feel least competent.

(Needless to say, I am writing this weeks later because I am searching
for a potential duplicate.)

Terry.


_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/