On Mon, Nov 29, 2010 at 4:20 AM, Robert Vehse <robert.ve...@gmx.de> wrote: > > 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 >
I like everything Robbie said, having been in his position before, I can agree with everything he said here. Chris
