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 <[email protected]> wrote: > > On Sun, Nov 28, 2010 at 18:50, Evan Schoenberg, M.D. <[email protected]> > 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
