Holger Freyther wrote: > So yes as mike said we might need to educate people to not use certain fields > (severity, milestone, component)
Remove "project management" fields like priority, severity, and milestone ? > and to stop the too many me too's. Actually > I think in most cases the confirmation is not really needed as the engineers > needs to be able to reproduce the issue anyway. It can add credibility to a confusing bug report, though. > We can add voting or just count the number of CC's I'm note sure Ccs are really a good indicator. Since bugs get copied to the lists anyway, people interested in their progress may not have much of an incentive to subscribe to the bug. A "silent" (i.e., doesn't trigger a mail to be sent) counter sounds like a good thing to try. Speaking of "silent", I wouldn't mind if only changes that add text trigger mails. Cc list changes tend to be irrelevant. Even changes of assignment, etc., are usually not interesting if you're subscribed to the list where the bug originally appeared. > Should one > discuss bugs on the mailinglist and then move that information into the > bugtracker? It would be great if the bug tracker would just record any discussion thread(s) that the bug report and updates spawn. That way, one could process bugs by mail, which should be a lot more efficient than the Web interface. Regarding hijacking, how about just ignoring the noise ? (And let others take care of the flaming ;-) - Werner _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
