Trac Spam

[Jordan]

In the event that we do not close user submission of tickets (which it
sounds like most people do not wish to do at this point), I believe
that Google Code would still help deter duplicate tickets.

All Google Code projects I have seen present tickets differently from
Trac in a beneficial way. Trac doesn't show you any tickets right off
the bat, so you're required to search (and use the right terms) just
to see if your ticket already exists. As others have pointed out these
searches can often lead to chains of duplicates upon duplicates with
one linking to another through to another. The Google Code projects I
have seen can immediately show the users the most recent or the most
popular tickets (by star rating) in a matter of seconds - click on
Issues, then sort by stars or ticket ID. We could list our tickets by
recency or stars by default. This means that it's effortless for me to
find out if a problem I'm having has been reported. I can't say the
same about Trac.

The star system certainly sounds just like the up/down arrow system we
have in Trac, but it's actually considerably more useful. It feels
familiar to people and so it is actually used (our arrow ranking
system seems to rarely be touched). Additionally when in use, it
allows for the sorting system I mentioned above - it fairly accurately
tells people how important their ticket is to the userbase (certainly
not all of our users, but likely a good sized subset). This in turn
will eventually represent how important this ticket is to our
developers as well - if a huge number of users are experiencing a
particular bug, then we should fix it with higher priority.

I feel like these usability enhancements would go a long way towards
improving our issue tracking and process flow.

Jordan



On Sun, Nov 28, 2010 at 7:55 PM, Zachary West <zacw at adium.im> wrote:
>
> On Sun, Nov 28, 2010 at 18:50, Evan Schoenberg, M.D. <evan.s at dreskin.net>
> wrote:
>>
>> Other than "then we don't have to run it on our server" is there any
>> *advantage* to Google Code issue tracking over Trac? As far as I'm aware,
>> today's spam attack is the first time in about a year we've done anything on
>> an administrative/server management level to keep Trac running smoothly -
>> this does not seem to be a significant burden.
>
> Keeping Trac up to date, etc., is a bit of a pain in the ass. It would be
> cool to not have to run this part of the project ourselves merely because
> I'm the one who has to maintain it. :) It's not hard, though, no; it rarely
> has any problems.
>
>>
>> The origin of the "move to Google Code" discussion appears to be that some
>> folks want ticket creation to be something we control rather than letting
>> users do it.
>
> I don't care for this idea..
>
>>
>> I personally think that the convenience of users submitting their own
>> tickets outweighs the problems with marking duplicates and closing bad
>> tickets, but I'm not on the front lines of Adium support.  It seems to me
>> that we should look into other mechanisms to reduce duplicate tickets rather
>> than creating a personnel-dependent bottleneck.
>
> I agree. However, which is more likely for our users to have: a Google
> account, or an Adium Trac account? I think we could get reports if users
> don't have to jump through hurdles to deal with us.
>
>>
>> In any case, we could easily set Trac not to let users create tickets;
>> moving to a whole new system is not needed for such a change.
>>
>> Similarly, we could delete all existing tickets, if "starting fresh" were
>> the goal, or we could create a new environment, keep the old one up for
>> historical access, and migrate any tickets we wanted.  I don't think that's
>> a very good idea, either, but my point is only that moving to a whole new
>> system is not required to accomplish this.
>> -Evan
>
> I agree, but a new DB would be cool too.
> Zac