Re: Triage Project Update

Am 04.09.2012 23:05 schrieb Joel Madero:
> I agree that FDO has some benefits but the limitation is really that each user
> is needed to query every time,  the possibility of overlap is great, and no one
> is really responsible for an individual bug until the query is made and someone
> takes the time to look into it. I'm not sure if others would agree but it seems
> like having a "group" of 50 or so and being able to just do those at your
> convenience makes people more likely to help and feel like their is an end in
> sight for "their portion". This is vs. just seeing a never ending list from FDO
> or even having to "teach" new users (or even not new users) exactly what to
> search for every time with FDO.

As for me (a rather unexperienced QA Newbie), I've chosen a somewhat  different
approach: I've first created two custom searches,

1) all recent bugs (reported within the last two days) for curiosity (just to
see what people report recently)

2) all UNCONFIRMED bugs from the last 14 days

From query 2 I picked a couple of bugs every couple of days to
reproduce/confirm/assign/close/whatever seemed appropriate.

That's just to show a slightly different approach, which is rather simple and
can be handled perfectly within bugzilla itself without any external tool.

Ok, the only problem was, that when a person starts reproducing a bug, it can
happen, that another triager just starts with the very same bug at the same
time. So some kind of lock signal was the only missing thing to prevent
duplication of work. However, this situation did not happen a single time during
my self-chosen "BugReviewWeek" ;-)

Another advantage: By the above process nobody (virtually) "blocks" 50 bugs for
a longer time period. Bugzilla queries are very adequate at every time, as all
works with live data.


> Similar to how developers assign themselves bugs and then can just go look at
> their own bugs ("My Bugs") it would be nice to have this ability for QA triagers
> but have it somewhat automated since it's just triaging, not programming. In the
> long run (once we're through the back log of 650+ that are really old), it would
> be amazing if we had a team of QA staff that signed up to have bugs "auto
> assigned" to them for triaging.

We have the libreoffice-bugs@fdo mailing list, which contains (nearly?) every
new bug. Could we use it somehow for this purpose? E.g. by replying to a bug or
forwarding it to the qa list or some such? (Just thoughts, nothing concrete)



 What I imagine:
> QA triagers "sign up" for components they are willing to triage and their "max"
> load
> New bug is reported, if the bug has a component listed the bug gets "auto
> assigned" for triaging purposes according to some rule(s)

Personally, I prefer not to sign up for a special component but to pick a recent
bug which kind of "attracts" me spontanously. But there might be other
opinions/preferences/arguments/approaches.


> For now the google docs works, FDO does not as it is now but I'll discuss this
> further with Bjoern, Petr & Rainer to see if we can come up with something more
> functional than the chaos that is FDO :) Or maybe I'm just not familiar enough
> with FDO to really feel comfortable myself with it, this is more likely than not
> true :)

:-)

I like your initiative. Please don't feel discouraged by my comments, I just
wanted to add a slightly different view. If people like your approach, that's
great! It does not contradict to mine (IMHO), as it's rather obvious if a bug
has been triaged or not. So we can all work together towards our common goal.

Regards,
Nino