Openmoko Bugtracker

Joachim Steiger roh at
Tue Aug 12 05:33:50 CEST 2008

Mike Montour wrote:
> On 11-Aug-08, at 9:16 AM, Holger Freyther wrote:
>> Hey,
>> the signal noise ratio of the bugtracker is in a state that I'm  
>> close to
>> ignoring it completely.
>> It can not be that:
>> 	- People say +1 and me too. It is not a popularity contest
> The first "me too" might be useful, confirming that the issue is real  
> and not just something that the original reporter was doing wrong.
> As for the "popularity contest", Bugzilla has a "voting" capability  
> that allows users to indicate the bugs that are most important from  
> their perspective. I don't know if Trac has anything similar.
>> 	- People playing with components, milestones, severity...
> It would help to have reporting guidelines on the front page of 
>    to tell users what the policy is. For example I recently re-opened  
> #676 and I changed its severity from High to Normal. I don't know if  
> that was the right thing to do, or if I should have left the severity  
> field as-is.

yes, please. when someone gets to write these guidelines i will happily
hack them into our skin, see

> Is it possible to configure Trac so that only certain people (OM  
> employees) can edit the components/milestones/severity fields?

in theory yes, but then i would be forced to work on loads of valid
requests from people to be added to that group.
currently all authenticated users have TICKET_MODIFY and TICKET_CREATE
as well as TICKET_EDIT_CC.

also see

> How about adding a "recently closed as duplicate" filter to the list  
> of available reports at , and  
> instructing users to look at that before reporting any new issues?  
> That would at least catch the case of users submitting multiple  
> reports for recent bugs, although it doesn't help when someone re- 
> discovers a months-old bug.

something like this?


Joachim Steiger
Openmoko Central Services

More information about the devel mailing list