How to Triage: Draft posted on wiki

[John Summerfield]

Christopher Beland wrote:
> (Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )
> 
> On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
>> I'm not sure it's a good idea for the triager to do the work of
>> splitting a report which actually deals with multiple issues up into
>> separate reports. The problem is that then the triager becomes the
>> 'reporter', and it won't be clear to the maintainer that the real
>> reporter is actually some guy on the CC list. This could lead to
>> confusion. I'd prefer to put the onus on the reporter to split the
>> issues up.
> 
> I was wondering whether cloning a bug would maintain the reporter?  If

Is "clone" like "fork?" Do you want two (or more) threads of discussion.

An alternative to my previous suggestion might be a subordinate bug, 
"this also occurs in ...." The parent bug cannot be closed (the software 
won't allow it) until all subordinate bugs are fixed too.

It might be that a bug report reflecting on F10 might be prompted to a 
parent, that points to F10 and any where else it occurrs. The F10 
subordinate bug could then be closed.

Discussion should be against the parent, and the original reporter 
should be kept informed of progress.

> not, then it's probably best for the reporter to file a new bug, unless
> the triager can reproduce the problem.

Er, the reporter has a problem in F10. Isn't it expecting a bit much of 
a reporter to install and test on RHEL[1] xx, Rawhide and anything else 
you can think of?

An _experienced_ triager could take a punt that "This might occur in ...."

1. yes, I know _this_ is Fedora. I can't help thinking RHEL matters too, 
because the bugs database is shared/




-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)