TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Summary: Documenting a **** user interface feature
Subject:Re: Summary: Documenting a **** user interface feature From:Virginia_Day -at- DATACARD -dot- COM Date:Wed, 19 May 1999 12:11:53 -0500
Many organizations have bug databases. I can have bugs written against my help,
and I can let programmers know about problems I've encountered by writing bugs.
All bugs get prioritized, and carried forward to the next release if not fixed.
(Not an immediate solution, but ...)
Many organizations also have a change control process using documents such as
ECOs and ECRs, and a group such as a change control board (CCB). Someone from
documentation should be part of this process, and might have input about which
problems are "show-stoppers." In extreme cases, they should be able to stop
shipment long enough to make the point that the software has a serious usability
problem. See if you can find out what process can help you make your issues
known.
Regards, Virginia
John Posada <jposada01 -at- YAHOO -dot- COM> on 05/19/99 10:16:35 AM
Please respond to John Posada <jposada01 -at- YAHOO -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
cc: (bcc: Virginia Day/US/DataCard)
Subject: Re: Summary: Documenting a **** user interface feature
I don't think anyone said "demand that the programmers
fix it", and if they did, they are wrong. Nobody
"demands" that anyone else do something. How would you
feel if the programmer "demanded" that you do
something, even if they felt strongly about it.
Instead, you define the issue, define what you believe
is the impact to the users to leave it the way it is,
and if possible, suggest an alternative approach to
the situation. Make sure that you report it accurately
and make sure it makes its way to someone in
management who should care about the problem (CC to
management works for me), then get on with the job you
are payed for.
If you described the problem and impact correctly, it
probably will get addressed unless there is a bigger
business case to not address it.
> Four people adamantly declared it a bug and demanded
> that the
> programmers fix it (I laugh!! I laugh!! I want to
> work where they do, in the
> world where programmers do what writers tell them).
>
>
>
From ??? -at- ??? Sun Jan 00 00:00:00 0000=
> Send "chat" messages offline--not to the
> whole list!
> Send commands to listserv -at- listserv -dot- okstate -dot- edu
> (e.g., SIGNOFF TECHWR-L)
> Search archives at:
>http://www.raycomm.com/techwhirl/archives.htm
> Find contractor info at
>http://www.raycomm.com/techwhirl/contractors.htm
> Send all list-related questions or problems to
>
>
>
===
John Posada
Western Union International
(w) jposada -at- westernunion -dot- com
(p) john -at- tdandw -dot- com
_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com