Quality Control Center - handling of bug reports

[Richard Gaskin]

Shao Sean wrote:
> It seems if the bug report is not for the latest developer build the
> enterprise users are testing nothing gets fixed.. I understand about
> the issues and what-not but 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..

On the 14th I wrote here:

     As Jacque has noted here many times, the RQCC is a part of
     their workflow process but not all of it.  Internally they
     use different systems for tracking progress, updating the
     RQCC in batches as time permits.

     You'll notice that every few months Oliver goes through
     the RQCC and marks dozens of things fixed in the span of
     a few hours.  It's not that the team was sitting around
     drinking for months and then suddenly got a burst of
     energy and did everything in one day, but just that the
     system that helps them best internally is separate from
     the public convenience they provide in the RQCC.

These two bug reports are good examples:

<http://quality.runrev.com/qacenter/show_bug.cgi?id=6264>
<http://quality.runrev.com/qacenter/show_bug.cgi?id=7490>

One notes anomalies with the size of default buttons on Windows and 
Linux, and the other with OS X and Linux.  The Win and OS X default 
button size issues were addressed long ago, and I know from contact with 
the team that the Linux variant of that bug has been addressed recently 
for v4.5 (see my post with screen shots from the team at 
<http://mail.runrev.com/pipermail/use-revolution/2010-July/143647.html>).

Those two reports are effectively duplicates, but have not been marked 
as such.  Moreover, half of each was addressed a long time ago, and the 
other half recently, yet both still have a status of "New".

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.

Without knowing the specific reports in question I have no opinion on 
those, but in general a key factor that makes the RQCC problematic is 
merely one of expectations management:  if there was a header at the top 
of each page there that noted that the RQCC is provided only as a 
convenience for the community and not reflective of actual progress, 
then folks could use it for what it is without expecting it to be 
something else.

This ongoing topic is illustrative of the reason so very few companies 
have any sort of public bug database at all.

Personally, I like having access to the RQCC, warts and all.  I find it 
helpful for a general gauge of scope, and some of the details posted in 
reports have been very useful in helping me find workarounds I need to 
get through the day.

But if RunRev decided to follow the convention used by the rest of the 
industry in not publishing any bug database, I would understand.

If the issues you reported actually still exist in the engine, closing 
those reports before they've been confirmed as fixed by you only makes 
them more obscure.  Even if the lag between the RQCC and the internal 
process they use annoys you, it does a better service to the community 
to simply leave the reports in place.  No one requires you to read them, 
but I read most of the reports there a couple times each year and learn 
a lot from them.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv