NewTicket

24 views
Skip to first unread message

Christian Boos

unread,
Mar 11, 2008, 4:08:58 AM3/11/08
to trac...@googlegroups.com
Hi,

I think we need to go one step further for preventing the creation of
abusive tickets.
Despites our very visible warning, still too many people feel tempted to
skip it and directly fill the ticket form and submit.

Now that t.e.o is using 0.11, what we could easily do is to redirect the
"New Ticket" main navigation button to a /wiki/NewTicket page, which
would be read-only like WikiStart and would contain the usual warning,
plus some "contextual" content that any of our wiki admin could adapt.

I'm thinking for example about the repeated tickets we get about
videolan's defective Git plugin...
Or MacPorts, or several other Tracs for which we have repeatedly
misdirected tickets.
We could inline some excerpt of the most frequently seen error messages
and redirect to the MostFrequentDuplicates page, etc. This is the kind
of "reactive" warning that can't really be done within the traditional
big red box.

At the end of that page, after some adequate warning ("If you're really
sure...") we could have the links: "create enhancement request", "create
bug report". That still won't get rid of all the defective tickets, but
I'm sure I'm not the only one to welcome any progress in that direction.

-- Christian

Erling Wegger Linde

unread,
Mar 11, 2008, 9:00:50 AM3/11/08
to trac...@googlegroups.com
Hi,

Isn't this a general problem with most public bug trackers? Wouldn't
it be nice to solve this once and for all with some new feature in
Trac?

What about making a search after a user has filled in and "posted" the
ticket, which lists similar tickets and asks the user again if he is
sure that this Ticket is different from the suggested tickets..? Just
an idea, couldn't help my self from posting it..

- Erling

--
Med vennlig hilsen
Erling Wegger Linde

Christian Boos

unread,
Mar 11, 2008, 10:25:04 AM3/11/08
to trac...@googlegroups.com
Hello,

Erling Wegger Linde wrote:
> Hi,
>
> Isn't this a general problem with most public bug trackers? Wouldn't
> it be nice to solve this once and for all with some new feature in
> Trac?
>

Most public bug trackers have indeed various means to scare people
away... a registration form is the most common, then a big warning (the
scariest I can think of is the Subversion one -
http://subversion.tigris.org/project_issues.html).
So the approach I suggested is something that most public Trac could
easily implement through configuration:

[mainnav]
newticket.href = /wiki/NewTicket

and from there, customize the NewTicket page as they see fit (that's
what I just did this morning, see for example
http://trac.edgewall.org/wiki/NewTicket, which is intended to be
half-way between what we had before and the Subversion example).

> What about making a search after a user has filled in and "posted" the
> ticket, which lists similar tickets and asks the user again if he is
> sure that this Ticket is different from the suggested tickets..? Just
> an idea, couldn't help my self from posting it..
>

Now that's exactly another idea I proposed some time ago (ugh, 3 years
ago actually, time flows ;-) ), but that didn't go anywhere
(see http://trac.edgewall.org/ticket/1069). It could probably be
resurrected as a plugin, similar in complexity to the ticket clone one.

-- Christian

David Abrahams

unread,
Mar 11, 2008, 2:15:58 PM3/11/08
to trac...@googlegroups.com

on Tue Mar 11 2008, Christian Boos <cboos-AT-neuf.fr> wrote:

> Hello,
>
> Erling Wegger Linde wrote:
>> Hi,
>>

>> What about making a search after a user has filled in and "posted" the
>> ticket, which lists similar tickets and asks the user again if he is
>> sure that this Ticket is different from the suggested tickets..? Just
>> an idea, couldn't help my self from posting it..
>>
>
> Now that's exactly another idea I proposed some time ago (ugh, 3 years
> ago actually, time flows ;-) ), but that didn't go anywhere
> (see http://trac.edgewall.org/ticket/1069). It could probably be
> resurrected as a plugin, similar in complexity to the ticket clone one.

Try filing a made-up bug at https://launchpad.net/ubuntu/+filebug

That system doesn't get in the way too much but also encourages people
to read automatically-found similar bug reports before they invest time
in writing a new one.

--
Dave Abrahams
Boost Consulting
http://boost-consulting.com

Erling Wegger Linde

unread,
Mar 12, 2008, 9:11:38 AM3/12/08
to trac...@googlegroups.com
On Tue, Mar 11, 2008 at 7:15 PM, David Abrahams
<da...@boost-consulting.com> wrote:
>
>
> on Tue Mar 11 2008, Christian Boos <cboos-AT-neuf.fr> wrote:
>
> > Hello,
> >
> > Erling Wegger Linde wrote:
> >> Hi,
> >>
>
> >> What about making a search after a user has filled in and "posted" the
> >> ticket, which lists similar tickets and asks the user again if he is
> >> sure that this Ticket is different from the suggested tickets..? Just
> >> an idea, couldn't help my self from posting it..
> >>
> >
> > Now that's exactly another idea I proposed some time ago (ugh, 3 years
> > ago actually, time flows ;-) ), but that didn't go anywhere
> > (see http://trac.edgewall.org/ticket/1069). It could probably be
> > resurrected as a plugin, similar in complexity to the ticket clone one.
>
> Try filing a made-up bug at https://launchpad.net/ubuntu/+filebug

I think this looked great! It should be possible to use more
information from the New Ticket form to create a better query though.
The more you can configure such behavior the better.

An example would be:
- Should bugs related to other components show up or not (it could be
a "global" bug, but it might be irrelevant..).

>
> That system doesn't get in the way too much but also encourages people
> to read automatically-found similar bug reports before they invest time
> in writing a new one.
>
> --
> Dave Abrahams
> Boost Consulting
> http://boost-consulting.com
>
>
>
>
> >
>

--

Jani Tiainen

unread,
Mar 12, 2008, 9:20:49 AM3/12/08
to trac...@googlegroups.com
Erling Wegger Linde kirjoitti:

> On Tue, Mar 11, 2008 at 7:15 PM, David Abrahams
> <da...@boost-consulting.com> wrote:
>>
>> on Tue Mar 11 2008, Christian Boos <cboos-AT-neuf.fr> wrote:
>>
>> > Hello,
>> >
>> > Erling Wegger Linde wrote:
>> >> Hi,
>> >>
>>
>>>> What about making a search after a user has filled in and "posted" the
>> >> ticket, which lists similar tickets and asks the user again if he is
>> >> sure that this Ticket is different from the suggested tickets..? Just
>> >> an idea, couldn't help my self from posting it..
>> >>
>> >
>> > Now that's exactly another idea I proposed some time ago (ugh, 3 years
>> > ago actually, time flows ;-) ), but that didn't go anywhere
>> > (see http://trac.edgewall.org/ticket/1069). It could probably be
>> > resurrected as a plugin, similar in complexity to the ticket clone one.
>>
>> Try filing a made-up bug at https://launchpad.net/ubuntu/+filebug
>
> I think this looked great! It should be possible to use more
> information from the New Ticket form to create a better query though.
> The more you can configure such behavior the better.
>
> An example would be:
> - Should bugs related to other components show up or not (it could be
> a "global" bug, but it might be irrelevant..).

That looked pretty nice.

One thing that came up in my mind when looking that "frequent" page.

Is there possibility to catch name of plugin that caused problems? Since
some reports seems to originate from plugins but there is not really any
indication what part/plugin was responsible for that particular bug...

It's very easy to assume that any error that appears on toplevel are bug
of Trac even some of them actually originates from some 3rd party plugins.

--
Jani Tiainen

Christian Boos

unread,
Mar 12, 2008, 10:11:04 AM3/12/08
to trac...@googlegroups.com

Yeah, it's possible, I've done that in #5516. However in its current
form, this adds quite a bit of code, so it has to be improved a bit.
I'll remove the "identify tracker in which the bug should be reported "
part and make the "verify if one of their source file is in the
backtrace" part leaner. While it's easy to identify the involved plugin
when it's a single file one, eggs are a different issue, as the name of
the plugin can't always be deduced from the name of the file.

-- Christian

Reply all
Reply to author
Forward
0 new messages