Quality Control Center - handling of bug reports
ambassador at fourthworld.com
Wed Jul 28 09:10:35 CDT 2010
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:
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
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
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
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.
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
More information about the use-livecode