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. > 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.
