Crashes with 2.8.1 dp4

[Bill Marriott]

Joe,

The bug reporting procedure has improved dramatically over the past few 
months. It's currently as simple as I think it could possibly be, given a 
web-based interface.

- Voting -- a standard feature of the open-source Bugzilla software employed 
by thousands of other companies -- is not required. It's used primarily to 
prioritize feature requests and to eliminate the need for people to post "me 
too" comments or duplicate reports. Most bugs are addressed without being 
voted on at all.

- Volume of reports is not a problem. However, the most effective bug 
reports follow a format which includes a "recipe" (minimal steps required to 
reproduce a problem) and a succinct description of what is expected to 
happen vs. what actually happens. Reports are less effective when users just 
write up a couple sentences that says, "Oh, such-and-such is broken!" and 
don't supply details about what's happening. Or users who send us their 
entire 5MB stack expecting us to figure out what is going on amidst dozens 
of complicated handlers.

- Being picky is not a problem. You should expect the software to operate to 
a high standard of quality. Having said that, different people have 
different ideas of what the desired behavior should be, so if there's any 
question about it, be prepared to explain why a behavior is a bug.

- "Publishing" bug lists is either not necessary or already implemented 
(depending on your point of view), as the contents of the Quality Control 
Center are open to everyone, whether they have registered an account with it 
or not. You can simply do a "power search" to list all unresolved issues or 
do a simple keyword search to see if your issue has been reported already. 
Kudos to Revolution for being transparent about this aspect of the 
software/business.

- Participation in the Open Beta is completely separate from the ability to 
use or register with the QC Center. But it certainly makes things more 
interesting, and you often will receive new software (with big fixes, new 
features, and other improvements) months before the retail release.

- I'm not going to say that reporting a bug results in instantaneous fixes, 
but the situation is vastly improved from just a few months ago. The system 
is actively reviewed and bugs are generally responded to quickly. It's a 
direct channel to the engineering team. This is in contrast to the use-rev 
list, which is not actively monitored by programmers. The reason is simple. 
The Quality Control Center is more structured than a mailing list. You can 
categorize, track, and manage issues effectively and efficiently, so you 
have a decent shot at actually fixing them.

The Revolution Quality Control Center can be found at:

http://quality.runrev.com