roh at openmoko.org
Tue Aug 12 05:33:50 CEST 2008
Mike Montour wrote:
> On 11-Aug-08, at 9:16 AM, Holger Freyther wrote:
>> 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 http://docs.openmoko.org/trac/
> 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.
> How about adding a "recently closed as duplicate" filter to the list
> of available reports at http://docs.openmoko.org/trac/report/ , 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? https://docs.openmoko.org/trac/report/12
Openmoko Central Services
More information about the devel