On Wed, 2009-04-15 at 15:09 -0400, Dave Jones wrote: > On Wed, Apr 15, 2009 at 10:56:57AM -0700, Adam Williamson wrote: > > > the setting of these fields - they might disagree with a triager who set > > their issue to Medium or Low, and set it higher. I've implemented > > similar systems before and that hasn't been my experience - I've found > > that reporters will often over-rate an issue on initial filing, but few > > of them will ever re-rate it once it's been set by a triager or > > maintainer. However, if this did prove to be a problem, there's a fairly > > simple solution: just restrict the fields, so that only Bugzappers and > > maintainers (and other usually empowered folks) can set them. That would > > solve that issue, if necessary. > > > > So, really, we just want your feedback: do you think this system might > > prove useful to you as a maintainer? Can you see any problems with it, > > A long time ago, I tried using it on kernel bugs for a while, and > gave up quickly. If it remains user-setable, it's utterly useless. > > Severity of a bug differs wildly between the people filing the bug > and the developer on the recieving end. OMG MY SOUND DOESN'T WORK > might seem incredibly urgent that needs fixing asap to a user who > can't listen to his mp3s, but at the same time if someone else > files a data corruption bug, it's severity obviously trumps it. > > The idea of triagers cleaning them up post-filing has two problems > minor: more bugspam in our mailboxes. > major: I tried lowering severity on bugs in the past, and got into > revert-wars with the bug filer. It quickly became obviously it's > easier to leave it 'urgent' and to just ignore the field. > > The only way I see it ever being a useful field is if it > isn't visible to anyone but the person the bug is filed against > They after all, are the only people equipped with enough > information to determine how severe a bug is in context > with every other bug. I did cover that specifically: in my experience you don't get many revert wars once triage starts setting the fields. If it turns out to be different in the Fedora case and we do, it would be fairly simple to lock the fields, and wouldn't cause any 'regressions' since - as we agree - the fields are basically ignored at present, so reporters are gaining any benefit from setting them anyway. Problem solved. On the mail spam...there shouldn't be much, because the triager is expected to make all initial changes on a bug at once - so they'd just be setting the priority / severity in the same operation as they either set the bug ASSIGNED or ask for more information. So it shouldn't actually increase the amount of generated mail any. Mostly at this point I'm looking for feedback on the way the mail is phrased, as the idea of sending it to -devel for developer feedback has been approved by QA / Bugzappers - I just want to make sure our proposal is properly phrased before sending it. Once it's sent to -devel is the point at which I'm looking for developer feedback on the actual idea. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
