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.
I'm sure many of us are unofficial testers, discovering and reporting bugs as we work through the use-and-abuse of our products and document what we find.
Anybody ever report a bug, only to find that your report was a duplicate?
How does the workflow function where you live?
What hoops do you have to jump through, to get your own issue/bug-report quashed as a duplicate of a pre-existing one?
We talked previously about how many steps a workflow should have.
One of our rules (generally sensible) is that the originator cannot resolve an issue.
That's fine, except, neither can a peer, apparently. We have to add it to the workload of a tester or a manager to get it merged or resolved.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.