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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
