Pretty much everything Robby said was great.. Here are some quibbles. On Nov 29, 2010, at 2:20 AM, Robert Vehse wrote: > > Other support-related change > - Kill the mailing list > - IRC, forums: users can help other users as well > - Mailing list means pure 1to1 (Adium Team member <-> user) support > which is too expensive > - Our time is better spent on the forum since everyone can read there. > I’m not sure on this one but I cannot think of objections right now.
I disagree. Having a blanket "If you have a problem and just want to dump it here, and are OK with it maybe not getting a TON of attention, go for it" bucket is a good thing. People like to email things, especially when they're upset. It also gives us important information about the "temperature" of issues. In fact, if we are de-emphasizing Trac for support, a form on the website (protected by a captcha, email address required) that goes somewhere (feedback, or elsewhere) would be awesome. Support means letting your users come to you in ways that they feel comfortable. Of course you need to make it clear which systems make it easiest for people to get help, but in the end, support is about helping people with their problems -- it's up to us to figure out how to do that. > Trac’s ticket database is huge > Absolutely. We have almost 15000 tickets now. Searching with or without using > “Custom Query” is a pain. If it were possible to set up a new database and > move tickets with useful information over, that’s the best solution I can > think of and which I’d like to propose. > > Which tickets are useful / should be kept? > Some statistics - of the 15000 tickets we have: > - ~8000 which were closed with the following resolutions: invalid, wontfix, > cantreproduce, duplicate, outofdate, notadiumcode > - ~3900 marked as fixed > - ~1200 assigned/new/pending > - ~1900 unknown > > So, I would argue the ~1200 tickets that are open (assigned/new/pending) are > useful. Many good, triaged ones in there, the others we should triage. Apart > from those, it might be useful to keep the ones that are mark fixed since we > reference them in our changelogs (not critical, though) and those closed as > wontfix and notadiumcode since these carry information on why some issues we > will not (be able to) fix (again, not essential). This way we’d able to > drastically cut down on the mass of tickets. I prefer Peter's idea of starting a new database w/ some stuff imported and leaving the old one up read only. At a high level, I think we can get rid of fixed tickets filed against things older than Adium 1.3, and tickets that haven't had comments on them in a while as well. --- My main concern with all of this though is who is going to do all this work? This sort of blue sky restructuring is great to think about, but I think it's also important to think about the low hanging fruit that can be done quickly and easily that will make a big difference. For example, I think reorganizing our site to de-emphasize Trac for support would be a big help, and doesn't seem like a ton of work. Similarly, let's bring out our in-app help documentation online (it's already HTML, no?) -- don't underestimate the power of Google! Link to it in the footer of adium.im and bam, Googling for Adium problems just got way easier. -Colin
