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
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.