Trac Spam

[Jordan]

I'd like to propose that we make the switch to Google Code for issue
tracking with the following configuration.

 1. We leave the Wiki in Trac for now but disable Trac's ticketing
system. Eventually we'll get the best parts of our docs in the trac
wiki into Google Code or whatever system we evaluate as best to manage
the documentation.
 2. We still lock out user submission of Issues, but allow voting
(star system). We encourage the use of the forums for users to submit
their bugs, following which we confirm or dismiss them. If confirmed,
then a dev creates an issue in the Google Code tracker to represent
the bug. Users who report well described bugs on the forums gain
access to the Google Code issue tracker.
 3. Only feature requests which are being worked on (or we really
think should be worked on) are added to Google Code. Others which are
good ideas, but not something a developer is interested in, remains in
a feature requests section of the forum.

The need to move away from Trac stems from most of us no longer having
time to manage it. It's always been a bit of a hassle, but in the past
2 years, the number of incoming tickets that never get touched just
keeps on increasing and we're not doing our users nor ourselves any
good by not being able to sift through them.

In one fell swoop we get to eliminate SPAM, deal with our ridiculous
amount of duplicate reports, stop overwhelming developers with insane
amounts of tickets to work with, and prevent the submission of poorly
described and/or unfleshed out reports (ie: no logging included). I'm
sure there's more benefits.

The only downside is having to spend a bit of time moving our tickets
from the next couple milestones into Google Code. All others can be
left behind for reference, but not for direct use in the new tracking
system.

Zac had already reserved the name, so I'd guess that he's thought
about this at least once or twice before. We have all discussed the
idea of using a better ticket management system in the past - I think
this is it.

I'd like to hear everyone's thoughts on this, particularly those from
Eric, Zac and Evan.

Cheers,

Jordan

Jordan



On Sat, Nov 27, 2010 at 11:45 PM, Jordan <jas8522 at gmail.com> wrote:
> I like Zac's idea of switching to Google Code, although re-creating
> dozens of feature requests and bug reports would be quite a hassle. Is
> there an import tool from Trac to Google Code?
>
> That said, we *could* start with a clean slate of tickets and only
> re-create those which we have milestoned for the next major and minor
> releases.
>
> Is it worth doing that? Do we lose any features that Trac has and
> Google Code does not? (Obviously only features we make use of now).
>
> Jordan
>
>
>
> On Sat, Nov 27, 2010 at 11:30 PM, Christopher Forsythe <chris at growl.info> wrote:
>> I don't think you realize how hard it is to update trac as compared to
>> updating os x or adium. Adium has a few customizations to boot that
>> would need to be worked with.
>>
>>
>>
>> On Sat, Nov 27, 2010 at 11:06 AM, Shawn Khan <shawn.khan at gmail.com> wrote:
>>> Hello all,
>>>
>>> I believe we should keep Trac updated as we do with Adium and Mac OS X.
>>> This might not fix everything but at least this is closer and we can file a
>>> ticket with them about our problem and see where that goes.
>>>
>>> Thanks,
>>> Shawn
>>>
>>> On Nov 27, 2010 11:52 AM, "Zachary West" <zacw at adium.im> wrote:
>>>
>>> On Sat, Nov 27, 2010 at 08:08, Jordan <jas8522 at gmail.com> wrote:
>>>>
>>>> We *could* also leave it as is ...
>>>
>>> I took out the big bat and deleted all the tickets by the user. Annoying
>>> spammer, taking advantage of Turkey-based absences.
>>> Another option is to upgrade to Trac 0.12 in the hopes that it fixes
>>> whatever problems we have and adds better plugins for anti-spam, or going to
>>> something hosted like Google Code's project stuff (I have the 'adium'
>>> project there: <http://code.google.com/p/adium>), though I'm not sure how
>>> much it has matured since I last looked at it a year or so ago.
>>> Zac
>>
>>
>