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.
Subject:RE: How does your team track document requests? From:"McLauchlan, Kevin" <Kevin -dot- McLauchlan -at- safenet-inc -dot- com> To:Ryan Pollack <ryan -at- clicksecurity -dot- com>, "Porrello, Leonard" <lporrello -at- illumina -dot- com> Date:Thu, 24 Jan 2013 10:09:10 -0500
We're using MKS (for a while longer - look up Mortise Kern Systems) for bug tracking and feature requests (as well as for software source control), and items arrive on my plate in various formats.
Some are bug/feature issues that have been addressed by developers, and are now moved to my plate to document - either how a new/changed feature works, or how to work around an issue that was not fixed. The preferred way is for the developer to create a new documentation issue associated with the finished software/firmware/hardware issue, but as often as not, I just get the original issue re-assigned to my box, with my name, rather than the name of a developer or tester, and with a note "Techpubs, please document this for customers - edit John's comments from the Resolution Actions section and include. Thanks.".
Some are change requests and feature requests from Support and from Sales-Eng, aimed directly at customer documentation. They often include FAQ items or use cases that nobody thought of when the product was released. ("You say your new customer wants to do ... WHAT!??!?")
Lately, as we've been switching (from waterfall) over to Agile, everything is either an Agile story or an Agile Task, still within the MKS system.
Somehow, all this will get translated into whatever terminology is used by the new source-control and bug-tracking system(s) as 2013 progresses.
But I (and my co-writer) will still be part of the same system that the developers and others use. I wouldn't have it any other way.
-----Original Message-----
From: Ryan Pollack
Sent: January-23-13 11:08 AM
To: Porrello, Leonard
Cc: techwr-l -at- lists -dot- techwr-l -dot- com; Robert Powers
Subject: Re: How does your team track document requests?
I like your idea of using the same issue-tracking software as the development team. I have always found this setup to be helpful. My developers use FogBugz to track product bugs and feature requests; I use the same system to track documentation bugs (issues with existing
documents) & feature requests (ideas/requests for new documents).
My stockpile of prioritized requests then becomes my backlog/macro-level to-do list. I pick tasks off the backlog and create daily or weekly to-do lists.
One benefit to this setup is that project managers can query the database and see where I am on docs. That way they can make conscious decisions about whether to ship given the current state of the docs or whether to ask me to focus on a particular area.
On Wed, Jan 23, 2013 at 9:44 AM, Porrello, Leonard
<lporrello -at- illumina -dot- com>wrote:
> I used Bugzilla at my last gig. It worked great. By now, they may even
> have developed a secure, customer facing interface.
>
> -----Original Message-----
> From: techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com [mailto:
> techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf
> techwr-l-bounces+Of
> Robert Powers
> Sent: Wednesday, January 23, 2013 1:50 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: How does your team track document requests?
>
> I've used various methods over the years: spreadsheets, to do lists, etc.
> We're considering using Bugzilla (bug-tracking software) now since the
> software engineers at my company are very familiar with it. We hope
> this would allow for more integration with the software development process.
>
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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See what's new in Doc-To-Help 2012 in a free webcast:
Read all about them: http://bit.ly/C1-webcast
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com
