Two key points come out of your discussions - information sharing, which is surprisingly difficult in the US now due to revenue recognition (my girlfriend who is a tax accountant is helping me understand the laws here), and then QC usage itself. QC started as a public self-support project ’skunkworks’ by developer relations, which we’re looking to enhance a great deal.

And not to discredit the hundreds of hours of work that resulted in over 10 000 issues reported in QC from being addressed! That’s a really good success story. Even with it’s weaknesses, QC is very usable and provides the team great information.

However, as it stands now - reports are coming in faster then CG internal staff can deal with them, and we need more active Sysops. Sysops will look into the areas they are interested, and the areas they are not will get neglected.

Voting help prioritize work, and limited votes focuses on the important issues - however for the serious but not very high profile issues, the small number of votes did not provide needed granularity.

I’ve taken samples of hundreds of QC reports in various areas, and a large number have 0 votes, a few have 1 to 5 votes, and a small number have over 5. Hence the directive to increase maximum number of votes to see if we can get more general feedback and create something closer to a bell curve.

As to solving the information problem - the basic ‘is codegear looking at it?’ - if it’s Open, it’s on our radar. Then it’s prioritized, which is the hard part right now with such limited voting feedback.

So recent changes will help to address those two major issues. We still can’t ever say ‘this list of bugs are what we’re planning to fix in an update’ - we do those discussions with our internal field test, which are under NDA.

Now, we’re fairly casual about who we let into our field test - anyone who wants to install the latest patch or build, which is usually a beta quality by the time we release to field test, can send me an email and ask to join. I’m usually fairly communicative and open with the internal field test. It’s much safer then worrying about SOX or revenue recognition by some inferred promise (as much as folks would like to hear it).

I agree about voting being problematic, we’ll be changing maximum number of votes. For the most part, developers look at QC as a repository for customer bug reports, and then product management looks at it for feature requests. We want to seperate the two purposes as much as possible, though some issues are ‘grey’ - major rework for performance improvements could be seen as either a feature or a fix

We are also considering the option of ‘I can reproduce this’ so that users can check a box, then a value is calculated, clearly showing how many users run into the issue. Personally, I think that is very useful especially to QA.

You can use the QC Windows client to report an issue, a link can be found here, where you must agree to the disclaimer :

http://qc.codegear.com/BCDownloadCGI.exe/disclaimer

Ok in the future I’ll post fix lists referring directly to QC reports. These should sync up on the day of release when the version number of the patch is pushed public. I was learning about that system when QA decided to nose in more with QC, so now am a full admin.

We’re looking at the clients in detail too, the team is happy with the client we use internally, and plan to improve the QC one to bring it up to similar level of functionality. The searching in the internal tool is MUCH more powerful, and I agree intuitive colors and information are a must.

More on the client as things progress. I’m pushing for about a year worth of improvements and work in several steps.

Since voting is so cumbersome, you will all see a change very soon - dramatically increased number of votes, and Sysops will have an increase to the number of votes they can put to an issue.

We’re trying to encourage more Sysops - QC was designed to be a community supported system, and we need plenty of Sysops to make that happen.

As to risk of fix - that’s taken into consideration by R&D during development of either major releases or of patches. The Delphi team puts a huge amount of effort into maintaining backwards compatibility. A flag such as ‘risky’ could be confusing unless used consistently.

Comments to and from QC - we’ll be taking care of that as part of merging QC and RAID, so that engineers work off the same system. I expect that will resolve that particular problem. It’s not productive to have to look at two systems to get all the current information.

Sorry for posting (again) a novel.

1. Response time problem. One of the main goals of any IT company (yours, ours) is to minimize the response time. How quick can you fulfill the customer’s requests. You must be focused on this. In fact, this is the main reason of existence of QC. No one from your customers (including me) will spend one of their most expensive resources (time) with QC if they doesn’t have pretty clear in their minds that their requests will be handled in a timely manner & in an appropriate way. Imho, you (CG) must clarify this first (see my other post in ng).