Feedback on the updated troubleshooting tech paper

["Dr. Stanley Doherty" <stan@modularwriting.com>]

This is a worthwhile revision of the original tech paper . . . my compliments. 

I have a few friendly suggestions to consider for addition:

1. Collaboration gateway: Individual troubleshooting topics are certainly 
   useful, but the real value of investing in focused troubleshooting 
   content has lots more to do with collaboration across 
   organizational barriers than building out some separate library
   of documentation topics. Organizations that are large enough to 
   consider DITA certainly have technical support, customer support, 
   or field sales organizations who have been developing diagnostic
   and troubleshooting information for years. Whatever the tech pubs
   team might think are useful XML content models for troubleshooting
   information is secondary to leveraging the logic and substance of
   existing troubleshooting content developed in other organizations. 
   
2. First steps: Section 3 of the tech paper doesn't mention the 
   primary business justification for developing troubleshooting
   content -- reducing the number of customer support calls. IAs 
   and managers planning to develop an initial library of 
   troubleshooting topics should buy the head of customer 
   support lunch and ask her/him for a list of the 50 most
   frequent support issues. Some 30 or so issues are most certainly
   suitable to be worked into DITA troubleshooting topics. It's 
   a win-win. Support can now feed the tech pubs team all sorts of
   field-tested content and the writing group can get on the 
   scoreboard with some proven content. Rewriting existing Support 
   content also helps writing teams shake out their XML templates
   and metadata. Not every writer is is strong in this area, so
   managers need to vet the writers as well as the writing. 
   
3. Collaborative design: Under the hood of the most popular
   knowledge managements systems supporting KCS
   (Knowledge-Centered Support), you find very similar fields
   and views for diagnosing and solving customer issues. Adding 
   yet another set of fields (XML element names) on top of 
   the existing ones doesn't make that much sense. Why not 
   recast the DITA content models to adopt the names of the 
   KCS fields that are already familiar to the organization. 
   Yes, there would be little consistency between the XML
   troubleshooting elements in Company-A or Company-B, but
   so what?  
   
4. Structured information exchange: Most any engineering 
   grad student would be able to write converters between
   structured database records in KCS systems and DITA
   XML troubleshooting topics (especially if they share 
   many of the same field/element names). Similarly, adding
   adding specialized DITA elements that correspond or
   link to non-DITA support or escalation tickets would
   be huge. DITA troubleshooting content should be an 
   extension of a corporate content strategy around 
   troubleshooting information. Finding ways to emphasize
   that role in the tech paper would be good.  
   
Using the troubleshooting topic type as a calling card for 
collaboration and not as an end in itself makes business
sense. DITA is late to the party. It has been easier for
Support organizations to publish troubleshooting information
or FAQs out of their KCS systems than to educate tech pubs
organizations on how to develop and curate enterprise-class
support information. 

DITA is quite capable of playing nicely in this collaborative space (perhaps a different tech paper). 

Let's play to our strengths where we can.