(reposting -- somehow my previous attempt to send this via email
was unsuccessful)
> I've seen similar threads before. The thing I generally take
> out of them, which I really tried to get MDV bug triagers to
> buy into, is follow up. Triaging isn't a drive-by operation,
> you have to follow up the bug. You really should be in CC for
> any bug you triage.
Hello,
let me add a little bit longer reply to this thread (actually, in
the end, it is very long). Actually, I think this conversation
about Ubuntu is very relevant to us as well. Maybe we are not
that far down this path as Ubuntu (because our triaging effort is
just starting?), but I see a lot of this “we are here to get
number of bugs down” mentality around.
Listen, if we want to close ALL our bugs in couple of minutes,
then it is quite simple to do — open a query with all open bugs
and then choose “Change Several Bugs at Once” and close them as
WONTFIX with a comment “Don’t bother us with your problems!”
After half an hour or so there would be no open bugs in Fedora[1]
Of course, after a little bit more time, Fedora would have
(almost) no users remaining, you would have also no access to
anything related to Fedora, and couple of nazgúls and/or balrogs
would be flying your way ;-)[2]
The point is hopefully obvious — the goal of bug triage is not to
get number of bugs as little as possible, but to help get fixed
as many as possible bugs. So, the question is obvious: what
actually IS the goal of bug triage? Using writing by the biggest
known authority on bug triage, Luis Villa[3],
1. free software QA must support the needs and desires of
developers in order to succeed
2. QA needs guidance from maintainers
3. QA must persuade hackers they are useful and inteligent
4. Bugzilla cannot be the end-all and be-all of communication
between hackers and QA
5. bugs need to be triaged, not just tracked
6. triage must be tied to release goals
7. triage new bugs agressively, or Bugzilla will quickly
terrify maintainers
8. closing old bugs, even completely unread, is unpleasant
but OK
9. triage rules can’t be just in one person’s head
Let me emphasize couple of things I see here. There is a lot of
talk about technology of bug triaging, goals and milestones, but
IMHO all this must begin and is understandable only in light of
the basic values which lead the bug triaging process.
1. The most important (albeit the words are unpopular and
probably slightly misleading, I don’t have anything
better) is the attitude of servanthood and humbleness.
Purpose of bug triaging is to make happy developers
— their work on fixing bugs, should be much more simple
with all bugs being de-duplicated, well triaged,
prioritized, and with all relevant information attached.
The part which needs to be made happy are users — their
bug reports being obviously (and visibly to them) and
courteously taken care of with clear path to proper
resolution.
2. The second most important thing in my opinion which should
be repeated all the time (especially when facing
components overflowing with unresolved and neglected bugs)
is
QUALITY FIRST, SPEED WILL COME AUTOMATICALLY!!!
Meaning that especially new bug triagers shouldn't be that
much concerned how many bugs they manage to clear out.
I don’t care a bit if you spend whole day (or two hours,
or how much time you have for bugzapping) studying and
trying to reproduce one bug, if in the end, repoter will
know what to do, and maintainers won’t have to spend time
on it. There are bugs (and components) where even after
two and half year of experience it takes me half a day to
find out what’s the problem and how to reproduce it.
3. It needs to be repeated, that bug triagers are here to
triage bugs and resolving them. The focus of bug triaging
should be making bugs accessible and palatable for
developers. If by chance you happen to find out duplicate,
or you find out that the bug has been actually already
resolved in the available package, great, but it should be
just lucky byproduct of your bug triaging not your focus.
Again, if after couple of hours of studying, testing,
searching for the stuff, you just make one good comment to
the bugzilla, it is much more worth than closing bug which
shouldn’t be closed, making angry maintainers, users and
making work for everybody involved.
Anytime I make a mistake (and I make plenty of them), it
is because I was trying to be more efficient and trying to
be faster, than I am with regards to the particular bug.
4. From the previous follows that bug triage should be done
in the close collaboration with maintainers of components
being triaged. This is the reason why I am so keen on
making bug triagers responsible for particular components
so that they could get into personal contact with
maintainers of the particular copmonent. Questions like
“What can I do for you?”, “What is your strategy in fixing
bugs?” (e.g., some developers prefer sending bugs upstream
and closing them there, while others rather keep
everything in our bugzilla), and of course “I am clueless
about this particular bug; what do you want me to do with
it?” are very useful. Ask them.
5. Bugs need to be triaged, not just tracked. For that they
need to be reproducible and therefore bug triager has to
try to reproduce them.
This one is very complicated one.
First of all, there are some bugs (and whole components)
where bug triager just cannot do much. There is just no
way how driver-related bugs (in kernel or xorg-x11-*
packages) can be reproduced without particular components.
Of course, if a triager is able to do it, because by
chance he has required hardware available, he should do
it, but somehow we just cannot do much.
And of course, there is always one person which has all
hardware needed for the reproduction of bug available
— reporter of the bug herself. If you can make her to
provide all information necessary, great. If not, well,
there are many many bugs where bug triager just gives up
and passes the bug to the maintainer as it is, knowing he
did all he could, and that bug maintainer knows about the
component more than all bug triagers combined. ;-)
However, it is also clear, that putting too high demands
on newbie bugZappers could discourage them and make the
learning curve just too steep.
OTOH, even when there are these (and others?) reasons why
the proper bug triage (which includes effort to reproduce
the bug) is not possible, it should be still kept in mind,
that this is a concession to real life problems, not an
ideal over which no-one should dare to get. No, we should
all be challenged to do the best what we can do, even in
the given time we cannot do everything necessary.
6. There is that whole issue of prioritization. Whenever
I talked with Luis about bug triaging prioritization was
the issue most on his mind. Currently, b.r.c doesn’t have
any good metrics for prioritizing bugs (all
priorities/severities/votes are manageable by reporters
and thus totally worthless) and nobody invented a good way
how to make it work. Any ideas are very much welcomed;
I have not much to say about it, just felt need to note it
here.
I guess that’s finally it. Comments are very welcome (and
needed).
Matěj
--
http://www.ceplovi.cz/matej/blog/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
I would like to die sleeping, like my father rather than
screaming and helpless, like his passengers.
=========================================
[1] Disclaimer: actually, I believe there are some protections in
Bugzilla, which make this not actually possible, and I believe
that not everybody has “Change Several Bugs at Once” button,
but I hope it illustrates my point enough, and it could even
grab your attention ;-).
[2] Interesting question whether balrogs have wings should also
be resolved somewhere else, see
http://tolkien.slimy.com/faq/Creatures.html#BalWings for one of
the longest discussions in the history of Usenet ;-).
[3] This time I am deadly serious — http://tieguy.org/talks/ is
absolutely the best what is available on bug triage on the
Internet, which probably means the best what is available
anywhere. The following list is actually from
http://tieguy.org/talks/OLS-2003-paper.pdf where you can get
much more thorough treatment of these issues.
http://tieguy.org/talks/GUADEC-2002-Bugzilla_Sanity.sxi is
absolutely crucial as well.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
