How to file a review comment offline
-------------------------------------

Review comments can also be sent in by email using the
following format.

Send emails to  ogarch-togaf-review-l (at) opengroup.org


The notation is as follows:

Subject: Bug in <document> <part>

@ page <no.> line 0 section <no. or name> objection|comment|editorial [comment]

Problem:
Explain why here.
Be sure to add sufficient explanation for someone not
familiar with the problem to be able to make a decision.

Action:
Be specific.  For example:

Change  "leftmost character"
to      "first character in the string"


Where document is one of 
TOGAF 8.1.1 (html edition)
TOGAF 8.1.1 (pdf download - g063s/g063se)
TOGAF 2006 Edition incorp. 8.1.1 (Hardcopy G063)

and part is one of 

I:Introduction
II:ADM
III:Enterprise Continuum
IV:Resource_Base



For example

Subject: Bug in Part I

@ page 1 line 1-4 section Introduction objection [AJ-1]

Problem:
The introduction does not read as well as that in the 2006 
edition of the published book (G063)

Action:
Replace the first two paragraphs with that from the 2006 edition
of the book (G063)



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

                              How to Comment

Review comments should be phrased wherever possible in terms of
specific wording changes.  Comments submitted in this way can then be
more easily discussed at relevant forum meetings, or voted on by
email.

We can automatically process and collate comments filed using this
form.  This allows all comments from many sources relating to a
single document to be collated and presented in page order in a
single Change Request Report.


In the Problem Area:

Explain why you have a problem here.
Be sure to add sufficient explanation for someone not
familiar with the problem to be able to make a decision.

In the Action area:

Be specific.  For example:

Change  "leftmost character"
to      "first character in the string"

(You can normally trust the editor to take care of formatting issues in such
changes, including use of the correct font et cetera, unless there is
something out of the ordinary)

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

Comment Categorization

There may be cases where the originator feels unable to provide
text, for example where a clarification is requested.  In such
cases there are two possibilities:
   - write down one of the possible alternatives.  This at least
   serves to illustrate your concern.
   - contact someone else, in advance, who may be able to suggest
   some wording.
Wording can be improved at the resolution meeting, but there
will not be time to create new wording, and no possibility
of subsequent off-line text generation.  To emphasize:
CHANGE REQUESTS WITHOUT EXPLICIT EDITING INSTRUCTIONS WILL
BE REJECTED.


1. Objections

You should only classify an issue as an "objection" if you would vote
against approval of the submission if that issue is not resolved.  Any
objection which is not supported by rationale, or which does not provide a
responsive proposal for resolution, will be deemed invalid, and reclassified
as a "comment".

2. Comments

If you wish to raise an issue where you believe that a better solution is
available, but the issue would not, on its own, cause you to vote against
approval of the submission if the issue were not resolved, you should
classify it as a "comment".

3. Editorials

Issues marked as editorial will not be discussed, they are included in this
mechanism as a simple way to bring such matters to the sponsors attention.
(If you see someone else classifying an issue as editorial, and you believe
it DOES need discussion or clarification, you should resubmit the point
yourself, with a different classification.)


Note that it could be helpful for you to include a company identifier and 
sequence number (eg mycompany 25) in the optional "comment" field within
the form.


-------------------------- end of file -----------------------------------