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.
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..
On Tue, Mar 11, 2008 at 9:08 AM, Christian Boos <cb...@neuf.fr> wrote:
> 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.
> 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.
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.
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.
> 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.
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.
> On Tue, Mar 11, 2008 at 7:15 PM, David Abrahams > <d...@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.
> 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 wrote: > Erling Wegger Linde kirjoitti:
>> On Tue, Mar 11, 2008 at 7:15 PM, David Abrahams >> <d...@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.
>> 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...
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.
> 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.
