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.
In our regulated medical device environment, we use Complaints and CAPAs
(Corrective And Preventive Actions). We track documentation (AKA
labeling) issues the same way we track engineering issues. When the
corrected documentation is released, the Complaint and/or CAPA can be
closed.
That having been said, there are *many* changes whose source is the
documentation review itself, and not any Complaint or CAPA. In those
cases, no tracking is necessary, since the problem and solution are
simultaneous and collocated.
> -----Original Message-----
> From: Julie Stickler
> Sent: Wednesday, May 13, 2009 11:48 AM
> To: Technical Writing
> Subject: Bug tracking and documentation
>
> I'm a software technical writer, and every software company
> I've worked for has had some sort of issue/bug tracking
> system in place.
> And they've all used the same issue tracking system that they
> use for software bugs to log documentation issues. Today I'm
> trying to write up how I'd like the process to work at my current job.
>
> The system works well when the issues logged are things that
> are clearly "right" or "wrong" like incorrect procedures,
> incorrect code examples, missing steps or procedures, etc.
>
> Where the system breaks down is when someone enters issues
> like "Guide X needs to be completely rewritten." Or someone
> enters pages of documentation reviews/comments as an "issue."
> Because our process requires QA to close issues, and our QA
> team really has no idea how to judge if this type of issue is
> "fixed." I end up force closing a lot of these, or listing
> them as "not a bug."
>
> So, I'd like to ask the group to share your collective
> wisdom. Does your company use an issue/bug tracking system?
> Do you use it to track documentation issues? Does your
> system work well, or not, and why?
>
This message contains confidential information intended only for the use of the addressee(s). If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing, copying, electronic storing or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this message by mistake, please notify us, by replying to the sender, and delete the original message immediately thereafter. Thank you.
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-