I don’t believe that there is a proper formal channel to report bugs - there have been a couple of postings about this recently. The Audacity websiste implies that you just send emails re bugs to the Audacity Helplist email a/c - see http://audacityteam.org/contact/.
I don’t think this is really a good way to handle bug reports, not least because there is no feed back to the bug-reporter and to the user community in general. I think there should be a formal section of the forum devoted to bug reports (actually 2 sections - one for 1.2 and one for 1.3). I would then like the developers to review these reports and triage them (weekly would be sufficient, it doesn’t need daily monitoring) - and provide feedback via the forum:
-
as to whether these are bugs - or if it is intended behaviour of the software
-
if there is a good workaround
-
when and in which release the bug is likely to be fixed.
All the normal sort of stuff that software development shops do when they do bug tracking.
The top of the section should have a permanent anchored posting which lists the known bugs. This could well cut down of the no. of postings that we get saying “this or that doesn’t seem to work …”
WC
Koz added the following comments in a different thread where I had posted similar thoughts
Re: Please, please help!!
by kozikowski on Sun Nov 25, 2007 3:07 am
<<>>
I’m 100% sure you can’t do that. “I can’t get LameLib to work, this is a bug, right?” If you can’t keep trouble postings out of the forum forum, there’s no hope for a bug forum.
No, it has to be an insider thing. You get to post bug reports after your 50th posting to help someone else and then only after you can recite the formal definition of a program bug without cue cards.
That’s a good start.
Oh, but I would certainly make it visible to everyone even if they can’t post to it. This will make them all crazy (this is my evil side coming out).
Koz
And on relection I agree with him in principle - we still need a channel where all can post - but the the triage indeed should done by the “insiders” to decide which are truly bugs and should be placed on the bug list. The triage is always a key part of the bug management process in all good software development shops, winnowing out the wheat from the chaff.
WC
The main problem is that triaging all the bug reports that get sent in consumes so much time that none of the bugs ever get fixed. It needs about three people’s full commitment to keep up with the flow of reports which are overwhelmingly false. There is a bug tracker, but it’s very deliberately kept out of sight to try and restrict the traffic to what is known to be genuine.