helps if I actually switch the sections around like I said...

This commit is contained in:
emmajane 2004-04-19 23:36:01 +00:00
parent 4d0283366c
commit aae15686c0
1 changed files with 21 additions and 20 deletions

View File

@ -224,6 +224,27 @@ and make any necessary changes. If changes are
<para>As a member of the review team, you will recognize a peer review document as one the author has submitted to the discussion list, specifically requesting feedback for inclusion of their HOWTO in the collection. This review can be performed by anyone subscribed to the discussion list (<ulink url="www.tldp.org/mailinfo.html#maillists" />).</para>
</sect1>
<sect1 id="techreview"><title>Technical Accuracy Review</title>
<para>Make sure the facts as stated in the document are correct, helpful, and on topic.</para>
<para>To do a technical accuracy review, you really need to know your subject matter,
probably as well or better than the original author. Use whatever other documentation is
available for your subject, including man pages, program documentation, other printed
books, etc. You might also use mailing lists on the topic, asking for third parties to
verify certain facts of which you are in doubt.</para>
<para>When doing this type of review, consider if the information is only valid for certain types
of hardware or software. If this is the case, make sure to note the limitations of the document within
the document, either within the abstract or as a note at the beginning of the document. For example, if the
solutions in the document only are relevant for one type or brand of hardware, make sure that that
limitation is defined. This will keep readers from trying to apply a certain type of technology to an application or
situation where it will not work. </para>
<para>The same should apply for the prerequisite knowledge of the reader. If prior knowledge of a subject is assumed or required, the author should say so somewhere at the beginning of the document, and it's helpful to ask that authors provide a Resource section for further reading, to bring readers that much closer to the required information.</para>
</sect1>
<sect1 id="languagereview"><title>Language Review</title>
<para>Because writers come from all types of backgrounds, there may be problems
@ -369,26 +390,6 @@ and make any necessary changes. If changes are
</formalpara></listitem>
</itemizedlist>
</sect1>
<sect1 id="techreview"><title>Technical Accuracy Review</title>
<para>Make sure the facts as stated in the document are correct, helpful, and on topic.</para>
<para>To do a technical accuracy review, you really need to know your subject matter,
probably as well or better than the original author. Use whatever other documentation is
available for your subject, including man pages, program documentation, other printed
books, etc. You might also use mailing lists on the topic, asking for third parties to
verify certain facts of which you are in doubt.</para>
<para>When doing this type of review, consider if the information is only valid for certain types
of hardware or software. If this is the case, make sure to note the limitations of the document within
the document, either within the abstract or as a note at the beginning of the document. For example, if the
solutions in the document only are relevant for one type or brand of hardware, make sure that that
limitation is defined. This will keep readers from trying to apply a certain type of technology to an application or
situation where it will not work. </para>
<para>The same should apply for the prerequisite knowledge of the reader. If prior knowledge of a subject is assumed or required, the author should say so somewhere at the beginning of the document, and it's helpful to ask that authors provide a Resource section for further reading, to bring readers that much closer to the required information.</para>
</sect1>
<sect1 id="metadatareview"><title>Metadata and Markup Review</title>