NAIUA: OpenROAD SIG

OpenROAD DARS: facts, perceptions, and what you can do

"I have sometimes joked with CA reps that DAR stands for "Don't Accept Responsibility"." -- recent posting on the openroad-users distributed email list.

OpenROAD users have been quite vocal on the distributed email list on the subject of system improvement requests, currently called "DARS". Users perceive that when they ask a technical support technician to enter a DAR, nothing happens. Yet OpenROAD developers will tell you that DARs almost unilaterally set the direction for the product. reports that developers spend about half of their time incorporating bug fixes (from Level 2) into upcoming releases, and the other half working on new features. In the OpenROAD 4.1 product, 80% of the new features were to satisfy DARs. In OpenROAD 4.2, 60% of the new features come straight from the DAR list. So why does the negative perception remain?

I think the main source of the problem is that CA doesn't post the DAR list. This universally unpopular policy decision leads to an even more unfavorable ripple effect for CA in the long run. First, because the list isn't posted, users have no way to gauge the number and complexity of the DARs which have been submitted, and consequently focus only on their own requests. Since the number of DARs is much larger than the number each site is submitting, this is bound to be a lose-lose situation for CA and for all end users. Second, when CA introduces a new feature based on a DAR, nobody recognizes this fact except the site which submitted it. So we can only reiterate to CA that we think it would be a very good thing if they would post their DAR list.

But what, you ask, can we do? Here are two suggestions:

First, write a good DAR in the first place. How does CA decide which DARs to act on? Durwin listed the following criteria:

• The DAR must call for a change which will benefit a wide constituency. The more generic and useful your request, the more likely it is to be implemented.
• The DAR must be possible. If you are calling for a major architectural change in the product, your DAR is not likely to be implemented, particularly if it will only benefit your site!
• The DAR should be as specific and detailed as possible. Many of the DARs implemented in OpenROAD 4.1 were entered by users who supplied detailed descriptions and screen mock-ups.
• The DAR should require a single change, not a whole laundry list.

Also, the "openroad-dars" mailing list is now available for people who want to record the DARs they have open with Computer Associates. If you are a member of the openroad-users mailing list, you are automatically a member of the openroad-dars mailing list. The main reason for establishing this second list is to enable you to filter the email better. Email sent to openroad-dars will automatically be prefixed with "openroad-dars" rather than "openroad-users".

To post a DAR, send email to .  In the email please include the platform, version, and patch level of OpenROAD, the StarTCC number of your issue, and the bug number if you have one.  Then provide a description of the DAR.

-----------
, Associate Director
GSB Computing Services
The University of Chicago
773 702-5183