Quality Control Center - handling of bug reports

[Ben Rubinstein]

As I've just accidentally posted a message to the other list (that was meant 
to be private) touching this, it's timely to come back to the use list and 
find this discussion ongoing.

In responding to another thread a month ago I checked stats for the reports 
that I've opened in RQCC over the years.  Few I think for the latest developer 
build as for the last few years I've rarely had time to do proper testing, let 
alone proper reporting, on bleeding edge builds, and have somewhat guiltily 
been relying on others to do so.

The current tally is:
	 34 unconfirmed (of which 22 enhancements)
	  3 pending
	 20 new
	  1 assigned
	155 resolved

I'm not happy about the 35, but I think the overall tally isn't bad.  And I 
suspect that some of the 59 unresolved may have actually been fixed.  But 
they're not updated.

Richard Gaskin wrote:
 > I can fully appreciate why they use a different tool for tracking
 > changes internally and why they don't make that public, and given that I
 > can also understand that updating the status field for reports in the
 > RQCC is a back-burner project done only as time permits, usually in
 > batches and almost always long after the issue's status had actually
 > changed.

I can't fully appreciate it.  I'm not sure what would be so awful about seeing 
the interchange between engineers, the notes made etc.  If it really needs it, 
I'm sure Bugzilla has some capability to make private notes that are only 
visible to certain users.  While seeing a private note that one couldn't read 
would be frustrating, it would be great to see evidence of progress.

And if it really is necessary to use a separate tool internally, then I think 
a much higher priority should be given to keeping RQCC status updated.  As a 
minimum, if an issue has been adopted into the internal tracking tool, it 
should be 'confirmed' in RQCC with a note of the reference in the internal 
tracking tool.  That would at a stroke relieve a deal of the frustration felt 
by users who've taken the time to report an issue and see it apparently or 
actually ignored.

But I also don't think it's reasonable that updating the RQCC "when time 
permits ... long after the status had actually changed".  Time will never 
permit - if this isn't worth doing now, there'll always be something more 
important.  The only exception to this that I would accept is that 
'resolve-fixed' might be deferred until release of a new GM.

Two reasons why I think this is worth the time: one is just PR.

The second is to preserve a valued resource. RunRev is not Microsoft.  It 
cannot employ hundreds of testers in a well equipped config lab. Rev is a 
fantastically complex product. There are inevitably masses of issues in Rev. 
RunRev cannot hope to find more than some of the ones in the new features that 
they are working on.  They can keep adding new features, each with new bugs, 
and never fix (because never find) more than a few of the old ones; I doubt if 
this is a route to massive success.  If they wish to do any better than this 
at improving the quality of the product, the work of their users in noting, 
isolating and reporting problems is absolutely essential.  Users will do this 
for two reasons: selfish (they want this issue fixed) and unselfish (they've 
found a workaround so it doesn't bother them any more, but think it would help 
others and the product if it was fixed).  Both motives will not survive the 
appearance that their efforts are wasted.

Keeping these users motivated, by taking the time to record that the bug has 
at least been read; certainly by recording that it has been put on the 
internal tracking tool ("assigned?"); and by making part of the engineer's job 
when they change the status in the internal tool, to also update the external 
one, is far far cheaper than any other possible way of getting that level of 
testing done.

Shao Sean wrote:
> I have pretty much stopped submitting bugs a long time ago and just
> recently closed all my open bugs seeing as they will never get looked at
> let alone resolved.

Both clauses of that are a tragedy.

Ben