Interesting comments

[Matej Cepl]

(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.