Interesting comments

[TK009]

Matej Cepl wrote:
> (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
>   
@adam
I fully agree, a "drive-by" can be worse than not triaging the report at 
all. I have to admit I was guilty of this at first. I took the words of 
triage 101(http://fedoraproject.org/wiki/TriagingGuidelines/Triage101) 
to literal maybe. "Never re-triage a bug!" Drive-by triage isn't in the 
best interest of the user/reporter, developer/maintainer or myself.

Notice I put the user first.

@Matej
One word I saw omitted in your reply was "user", hacker doesn't really 
work as a substitute for me. What about the user? Is a product really a 
product without a consumer? Developers/maintainers are not to only part 
of this equation.

You made some very good points in your reply. Triage should never be 
about numbers, but about communication and quality.

I see this as the primary objective of triage-
"...acting as a bridge between users and developers to aid in fixing and 
closing bugs."
Nothing there about numbers of any kind. Everything else is secondary.

"For that they 
       need to be reproducible and therefore bug triager has to 
       try to reproduce them."

Respectfully disagree here. I see reproduction as a bonus, not a 
requirement. Time spent trying to reproduce doesn't pay off in 
production or quality, in a few cases it might but for the main, no.
 From Traige 101: What wasn't done - 10) try and reproduce/make test 
cases, etc.

I like to respond further but damn brother to much in one email =).

TK009