Am 29.11.2010 um 01:04 schrieb Peter Hosey:
Robby? What say you?
Hey folks,
I like to write as concisely as possible, but be prepared for a longer
email.
This email discussion thread touches the topics of support, bug
tracking and documentation which - as you will know - have been the
primary domains of my work for the Adium Project. So naturally, I’m
very excited that these topics have gained so much attention and I’m
confident some practical improvements will result from this
discussion. (At the same time, I’m baffled considering that over the
recent years I’ve only seen few people consistently work in Trac and
the forums but move on. ;))
Given the importantance of this discussion to me I’ve tried to
approach these topics of support, bug tracking and documentation
holistically. Questions such as the following seem essential:
- Should we keep using Trac?
- What does Trac do for us currently? What should it do? What
shouldn’t it?
- What issues do we have with Trac?
- How should Support work?
Should we keep using Trac?
First, I’m pretty clear that I would rather not move to a different
system than Trac and the Cocoaforge forums for the following reasons:
1. Familiarity: most of us will have turned expert Trac users over the
years. While I have seen Google Code / Google Groups, I am not as
familiar with it as I’m with Trac. Trac is also used by many, many
open source Mac applications (Transmission, Perian, Handbrake,
Cyberduck, VLC) and very importantly, Pidgin.
2. Worth: our Trac ticket database carries invaluable information we
and users have accumulated over the years costing us and them time and
effort. Let’s not throw it away!
3. Our forums are established, I love the idea of Cocoaforge as a
central place for Open Source Mac software.
4. From my admittedly small experience with Google Code / Google
Groups, the interfaces for forums/mail and bug tracking are inferior
to what we have.
5. I’d rather not rely on Google.
In my opinion, we should continue using Trac and our Cocoaforge
forums. But I realise there are issues with how we use Trac,
especially. (I will respond to further arguments versus Trac in a
separate email.)
Trac confuses the average user
I agree. The average user shouldn’t have to deal with it. In fact, for
a long time I have been thinking Trac shouldn’t be a venue for support.
What does Trac do for us currently?
Currently, we have a Support & Development tab which leads to
WikiStart. WikiStart itself links to dedicated Support and Development
pages which link to other pages (see below). This all happens on Adium
Trac’s Wiki.
Support page links to:
- Documentation: Adium Help (in-app), Wiki documentation (which mostly
matches Adium Help), FAQ
- Troubleshooting page
- Support venues: Forums, IRC, Mailing list
- Filing tickets, bugs and enhancements
Development page links:
- Development resources, information on contributing (Coding,
localisation etc.)
What shouldn’t Trac do? / Proposed changes to the Adium website
Again, the average user doesn’t like Trac and shouldn’t have to use
it. Therefore, I propose using Trac for Development only, not for
Support suggesting the following changes:
- Set up a dedicated Support tab that links to an ordinary, non-Trac
page which links to support resources/venues (Troubleshooting page
should become an ordinary page as well)
-Bring in-app Adium Help documentation online, link to it from the
Support page (means: no more Wiki pages that are not development-
related)
- Rename “Support & Development” to “Development”
- Move bug filing to “Development”
- Casual users will report issues in the forums, in IRC
- Think of bug/enhancement request ticket filing as a way of
contributing to the Adium Project since constructive, useful reports
take time and effort
I'm confident we will get less tickets that way, and these tickets we
will get will be of higher quality. Drive-by complaints will end up in
the proper support venues.
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.
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.
Summarised proposals:
- Set up a dedicated Support tab that links to an ordinary, non-Trac
page which links to support resources
- Bring in-app Adium Help documentation online, link to it from the
Support page
- Rename “Support & Development” to “Development”
- Move bug filing to “Development”
- Kill the mailing list
- Set up new Trac database, move over useful tickets
Cheers,
Robbie
