On Nov 28, 2010, at 6:04 PM, Peter Hosey wrote: > On Nov 28, 2010, at 15:50:42, Evan Schoenberg, M.D. 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? > > In favor of Trac, Adium's Trac is pretty well-customized at this point. > > Against it, Chris (and now Zac) say Trac is a PITA to maintain. > > There's also defending it against spam. On the flip side, how well can we > make GCH resistant to spam if spammers start hitting it? There's no > GCH-ticket-system analog to Google Groups's new-subscriber-probation feature.
AFAIK, GCH should be pretty good at defending against automated spam. We require a Google Account to file issues (which may be a non-sell for Adium, I dunno) and I think there's some more protection under the hood as well (I've not checked, but it seems to work well enough for chromium.) > >> 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. > > That's a separate issue. We can make users create tickets or file them on > behalf of users whether we switch to GCH (or something else) or continue > using Trac. > >> 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. > > What really matters is, are you on the front lines of fielding user-submitted > tickets? I know I'm not. Not having to deal with user-submitted tickets (most > of the time) is a big part of why I like Growl's we-submit-them-for-you > system. > > Robby? What say you? > >> It seems to me that we should look into other mechanisms to reduce duplicate >> tickets rather than creating a personnel-dependent bottleneck. > > There's no mechanism in the world that can do that. The problem is users > don't search (and cannot feasibly search), and since a single problem may > have up to a dozen ways of stating it (e.g.: contact list, contacts list, > friends list, buddies list, …), even if they do search, it may not find > anything. > > Worth noting: Filing tickets on behalf of users only reduces duplicates in > the ticket system. Having users report bugs by email (the way they like to) > would increase bug-report volume, which is both good and bad: It means more > incoming duplicates of the more common bugs/problems (which we would all > resolve down to a single ticket), but also means we may get a rare bug > reported that might not be under the current system. > >> 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. … my point is >> only that moving to a whole new system is not required to accomplish this. > > Several of us have said this already. > > The main reason why changing ticket systems is on the table is that, if we're > going to start with a fresh DB, this would be a fine time to execute such a > change if we want one. > >
