Revised 18 September 2004.
Requirements for IR system.

1a. Open Web access with simple search capabilities such as:

(a) Display/print Issue #xxx
(b) Display all "open" Issues,
etc.

1b. Extended search capabilities for internal users.

2. Ability for anyone to enter new IRs directly through web based forms.
   Ideally, this includes a preamble page which explains stuff to user.

3. Will serve as an archive for old IRs
(Must store several hundred, plus searcher must be able to easily
 select or not old stuff in searches. We could implement this by
keeping multiple databases. Then transference between databases is an
issue.)

4. Ability to add notes/attachments to an Issue.

5. Support for the following fields and values:

VHDL Issue Number: (automatically generated)

Language Version: (Supplied by submitter,defaults to current version)

Classification(Tracking category): 
                Examples
                Notes           
                Language Deficiencies and Enhancements
                Language Definition Problems
                LRM Terminology, Grammar, and Typographical Errors
                Request for LRM Interpretation

Summary: (Supplied by submitter)

Relevant_LRM_Sections: (Supplied by submitter or reviewer)

Related_Issues: (Supplied by submitter or reviewer)

Key_Words_and_Phrases: (Supplied by submitter or reviewer)

Date Submitted: (automatically generated)
Date Analyzed:  (Supplied by reviewer)
Author of Analysis: (Supplied by reviewer)
Revision Number: (automatically generated)
Date Last Revised: (automatically generated)

Authors_Name: (Supplied by submitter)
Authors_Phone_Number:
Authors_Fax_Number:
Authors_Email_Address: 
Authors_Affiliation:   
Authors_Address1:      
Authors_Address2:
Authors_Address3:

Current Status: (Initialized to Submitted, changed by reviewer) 
        Submitted
        Analyzed
        ISAC-Approved
        VASG-Approved
        Superseded
        Closed
        Forwarded

Resolution for Current Version (Initialized to Unknown, changed by reviewer)
          No change needed
          Unknown
          No changed planned (aka No change-too bad!)
          Interpretation Issued
          Language change suggested (devised)
          Language change needed
          Duplicate of ...
          Forwarded to ...
          
Superseded By: (Supplied by reviewer)

Description of Problem (Supplied by submitter)

Proposed Resolution (Supplied by submitter)

VASG-ISAC Analysis & Rationale (Supplied by reviewer)

VASG-ISAC Recommendation for current standard (Supplied by reviewer)


VASG-ISAC Recommendation for Future Revisions (Supplied by reviewer)


----------------------------------------------------------------

Possible mapping for Bugzilla
-----------------------------

Suggested by Peter Ashenden <peter@ashenden.com.au>, 7-Oct-04


Product: Create a product for each standard (eg, P1076, P1076.1, ...)

Component: Create a component for each part of a standard (eg, main
document, UML information model, ...)

Status: Interpret status values as follows:

  Unconfirmed -> Submitted

  New -> Initial check on validity done and initial assignment done

  Assigned -> assignment accepted

  Reopened -> Previously resolved but resolution disapproved

  Resolved -> ISAC approved

  Verified -> Resolution approved by WG

  Closed -> Resolution implemented in a published document (an
	    Explanation, Interpretation, Erratum, Corrigendum or
            Revision) if required; Submitter advised of resolution

  Note: Verified status doesn't provide for tracking separate approval
  by ISAC and VASG.  This would need to be handled procedurally, for
  example, by ensuring that an ISAC approved resolution is immediately
  forwarded to VASG for approval.

Resolution: Interpret resolution values as follows:

  Fixed -> A deficiency is identified and a remedy determined.  An
	   interpretation is to be published in an Interpretation
	   document.  A change is to be published in an Erratum,
	   Corrigendum or Revision document.  Both may be required.

  Invalid -> No deficiency is identified.  An explanation may be
	     provided for publication in an Explanation document.

  WontFix -> A deficiency is identified, but no remedy is to be
	     provided.  An explanation of the reason for leaving the
	     standard unchanged may be provided for publication in an
	     Explanation document.

  Later -> A deficiency is identified, no remedy is provided, but the
	   deficiency will be reconsidered in a later revision.  An
	   explanation of the reason for leaving the standard
	   unchanged may be provided for publication in an Explanation
	   document.  When the issue is to be reconsidered, a new
	   issue should be opened for the new standard revision.

  Remind -> unused

  Duplicate -> The issue is a duplicate of another issue for the given
	       version of the standard.

  WorksForMe -> unused

Assigned To: Person responsible for analysis

URL: unused

Summary: One-line description of issue

Status Whiteboard: not officially used

Keywords: normative, informative, example, note, terminology,
	  grammar, typo, definition, interpretation, explanation,
	  discussion
	  (These should be checked and/or added as part of initial
	  review of a submitted issue.)

Platform: unused

OS: unused

Version: revision or amendment of a standard

Priority: priority for resolving the issue

Severity: Interpret severity values as follows:

  Blocker -> unused

  Critical -> unused

  Major -> unused

  Normal -> Technical

  Minor -> unused

  Trivial -> Editorial

  Enhancement -> Request for enhancement

Target Milestone: unused

Reporter: Submitter of the issue

CC List: users can add themselves to watch an issue

Attachments: optional test cases, revision of package code, etc

Dependencies: resolution dependencies between issues

Votes: unused

Additional Comments: Initial detailed description by submitter,
comments by reviewers, analysis and rationale, descriptions of
attachments, ...