Great advice, Chipp.
As one who recently had two or three bugs fixed directly due to my
efforts, it really happens. What helped immensely was that I
included a video clip to show events leading up to the problem, and a
talking narrative at the same time. Also the crash reports furnished
by the operating systeme are invaluable. I always try to get a nice
'package' together before making a report and it really pays off.
It took hours, but was well worth it.
On the mac, the shareware iShowU is wonderful for this, and if you
use the 'apple animation' codec, the files can be quite small.
http://www.shinywhitebox.com/home/home.html
- it's $20 and with a $40 USB headset you can make pro quality
how-to videos of any size. I found the audio out of the headset
(logitech at Radioshack) was more appropriate and intelligible than
any of my pro vintage microphones.
With Rev having hundreds of bugs to go through, anyone serious about
getting their bug fixed would be wise to create:
1) a clear explanation of the bug
2) a recipe for replcating it
3) if possible, a demo stack showing it
Furthermore, those who wish their bugs fixed can also do a bit of
research by contacting other developers here to confirm the bug before
posting it.
Typically, when I discover a bug in Rev, I try first to break it down
into it's simplest components and try and create the most
straightforward and basic recipe for repeating it. Then I create a
simple bug demo stack, post it online and ask others to verify it.
Once verified, I then post the bug, with the stack, to bugzilla. I
have found this methodology has enabled most all of my reported bugs
to be fixed in a very timely matter.
--
stephen barncard
s a n f r a n c i s c o
- - - - - - - - - - - -
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
