Watch, Follow, &
Connect with Us

Please visit our new home

Public Report
Report From: QualityCentral/Client Interface    [ Add a report in this area ]  
Report #:  1492   Status: Open
All entered workarounds should be immediately visible to everyone
Project:  QualityCentral Build #:
Version:    1.0 Submitted By:   Dave Rowntree
Report Type:  Suggestion / Enhancement Request Date Reported:  6/12/2002 7:45:21 AM
Severity:    Serious / Highly visible problem Last Updated: 3/12/2004 12:25:47 PM
Platform:    All versions Internal Tracking #:  
Resolution: Retest (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (26 Total Ratings)
4.69 out of 5
Total Votes: 33
Workarounds should have a status tag which defaults to 'untested' when they are created.

As soon as they are created they should be immediately visible to everyone.

Their status can be updated as they move through the system.
Steps to Reproduce:

Peter Morris at 10/18/2002 4:01:34 AM -
I agree with this 100%.

I keep forgetting that workarounds are not instantly visible.  I tried adding a workaround to a closed report, and nothing "seemed" to happen.  The workaround didn't appear, and no message was displayed (failed or otherwise).  This gave me the impression that it hadn't worked.

I found this report while checking to see if anyone else had already posted this as an error, seeing your report reminded me that workarounds are not visible until approved.

I think a list of all workarounds with a status of "confirmed" or "unconfirmed" is an excellent idea.  The user can then decide if they wish to attempt to use an unconfirmed workaround or not, and it would be MUCH less confusing.

Peter Morris at 1/18/2003 11:18:42 AM -
Or maybe the workaround could only be visible to the person who entered it until confirmed, just to show them that they haven't forgotten to enter one.

Philippe ALLAIN at 2/18/2003 10:40:25 AM -
I fully agree that a posted workaround should be immediately visible to everyone with indeed a flag telling whether it's officially tested or not.
We, developers, loose so much time tracking bugs and trying to find workarounds that we deserve the right to test on our own machine a  workaround found by someone else even if it's not perfect or officially approved. It's time we need to win here!
If the proposed workaround does not work in some situation, then it can also be reported and again everyone can benefit form this new information.
There is no point hiding this information. This is an important contribution from someone to the community so let them (the community) have the possibility to make use of a may be good solution asap.
Telling all that, I think that even the flag is not necessary.

John Kaster at 3/12/2003 2:56:24 PM -
The only way I would find publishing all workarounds before reviewing them is if we indicate that it is not reviewed or approved as an official work around.

Dave Rowntree at 3/14/2003 3:08:36 AM -
John Kaster said - "The only way I would find publishing all workarounds before reviewing them is if we indicate that it is not reviewed or approved as an official work around.

That is what this report is asking for :)

That's what the workaround status is for.

Dave Rowntree at 3/14/2003 3:16:45 AM -
My own preference would be for the workarounds UI to be identical to the Comments UI. Each top level entry would be a workaround and comments could be added hierachically against it. The structure would then be in place for a workaround to evolve.

Nick Hodges at 6/3/2003 7:29:50 AM -
I totally agree with this suggestion.

Workarounds can be clearly marked "APPROVED" or "UNAPPROVED".  Users can act accordingly.  I see no reason to babysit developers any more than that.  

Workarounds are a key part of the value of QC, and making them visible right away makes for a better QC system, happier customers, and vibrant community.

Kjell Rilbe at 6/16/2003 10:58:46 PM -
Like I've suggested in the QC forum, perhaps there should be three states instead of two:

1. UNTESTED - new, noone has verified it.
2. TESTED - has been verified by at least one QC sysop.
3. APPROVED - has been verified by Borland.

Currently, even approved workarounds might have been approved by a level 1 sysop instead of Borland or even TeamB. So the fact that a workaround has been approved is currently NOT the same as the workaround having been verified and approved by Borland.

Will DeWitt Jr. at 6/17/2003 2:57:52 AM -
Agreed, Dave, would it be possible to add in Kjell's idea for 3 states rather than the 2 states your current report implies?  I don't know how popular the idea of approving workarounds by Borland will be, but if there's even a chance they might have 'approved' workarounds, having the capability already existing in QC would be a good thing.

Dave Rowntree at 6/17/2003 4:20:07 AM -
One of the reasons I didn't (or tried not to) imply how many states there should be, or what they should be, was to leave the request as open as possible, so Borland has as little as possible to object to in this report. If you feel that the report implies that there should only be two statii, then I obviously didn't succeed :(

I agree there should be more than Untested and Tested, but I think the problem may go deeper than the three suggested. Perhaps there should statii indicating whether a work-around is currently being tested by a sysop, or by Borland? How would we deal with rejections, bugs found due the workaround, updates to the workaround, etc, the way the work-around system is designed at the moment. There is no-where in the work-around system that allows comments against work-arounds (to report problems for example), or handle work-around revision updates, etc.

Personally, I disagree with a lot of the current implementation of work-arounds. and would prefer to see the whole concept thrown open for discussion. Most of the functionality of QC is based on another similar product quite familiar to Borland <g>, and as such is inherited from tried and tested methodology. Work-arounds do *not* come from that background and are a new concept in QC.

Work-arounds could, for example, provide the source for an automatic update program that updates your source VCL units to incorporate all Tested/Approved fixes, but certainly not in their current implementation.

How can you currently easily obtain all the updates for a given product version and 'Area' to update your own Borland source units? You can't. Work-arounds could ( and IMHO *should*) be designed to provide a fast and easy turn-around solution for correcting known Borland bugs.

Server Response from: ETNACODE01