-*- Mode:Text; Fonts:(MEDFNT) -*-

(hardcopy-file "it:keith;rowe-bugs-doc.text"
	:page-headings nil
	:printer "cs-laser")

  
                                 MEMORANDUM
  
  TO:     Wendy Rowe
  
  FROM:   Keith Corbett
  
  DATE:   July 18, 1986

  SUBJ:   Confusion over "Known Bugs and Limitations"
  
  COPY:   John Salis, Ron Rando, Dan Thomas, Sarah Smith
    
  The release 3.0 document, "Known Bugs and Limitations", is very
  helpful both to customers and LMI technical support people. But
  there seems to be some misunderstanding in Engineering regarding
  when, and how, bugs get documented. 
    
  Here's an excerpt from a recent bug-mail exchange that is
  illustrative of the apparent communications problem. 
  
     --------------------------
     
     Engineer 1:
     
        This is supposed to be Get Q Register, not the Information
        Management System.
     
     Software Support:  
     
        Is this in "Known Bugs and Limitations"?
     
     Engineer 2:
        
        Shouldn't be now.  Fixed in SRL 3.101.  (Along with a nasty ZMail
        sort-of-bug.)
     
     --------------------------
    
  My concern about the second engineer's note is that it implies
  that bugs can be "un-documented" when they are fixed in a patch.
  Clearly this can't be the case until the bug fix has been
  tested, validated, and incorporated into an actual release that
  is fully documented. This is illustrative of a misunderstanding
  by engineers generally of what a software cut-off release means.
  My thoughts on this are as follows:
    
  As another release is assembled and proposed for distribution,
  then the documentation should be updated to reflect the changes.
  Whereas Engineering can work in the continuous spectrum, one
  patch fix at a time, the rest of the world deals with the
  cut-off points that Engineering establishes. 
    
  Further, I believe it is each engineering's responsibility to
  keep Documentation fully informed of the impact of each
  modification, so that changes can be reflected in all documents.
  As a former tech writer, I didn't appreciate having to do
  detective work to stay up-to-date.  In conversations with
  Engineering, I get the impression that there is no formal
  mechanism by which engineers and writers get together to update
  release notes and bug documents. 
      
  For example, Engineering has informally sent Beta III (level
  3.93) to MCC (and nowhere else that I am aware of).
  Manufacturing is currently making tapes to distribute it to the
  3.0 beta sites.  This is the version Engineering believes is its
  "best shot" to date, and that which we should consider for
  official release. 
    
  So, 3.93 is the release that the current documentation must
  reflect; not one patch higher, or lower. 
    
  The criteria for what bugs to report are another point of
  confusion.
  
  Please add these concerns to the agenda for the next Release 3.0
  project team meeting, and let me know when this meeting is
  scheduled and what else is on the agenda. 
  
  
  KMC