v01INF4: guide-rev - Reviewing Guidelines for comp.sources.reviewed
Andrew Patrick
csr at calvin.doc.ca
Sat Apr 27 07:16:32 AEST 1991
Submitted-by: Andrew Patrick <csr at calvin.doc.ca>
Posting-number: Volume 1, Info 4
Archive-name: guide-rev
Comp.Sources.Reviewed
Guidelines for Reviewers
(Version 1.3)
This document is designed to provide guidelines and suggestions for use
while reviewing software for the news group "comp.sources.reviewed".
It also provides potential submitters with information about what the
reviewers will be looking for, and may be useful to others who are
asked to evaluate software.
These guidelines may change as we gain more experience in reviewing
software, and comments are welcome.
Be Timely
---------
If you cannot provide a review of a submission in a reasonable amount of
time (say 1-2 weeks), then please ask the moderator to select another
reviewer. If you decline to review a submission because you are too
busy, your name will be placed at the end of the reviewers queue. This
means that there may be some period of time until you are selected to
review another submission (depending on your areas of interest and
expertise), but that is probably what you need in this situation anyway.
If you refuse a package because you don't have the equipment or skills
to do the job (reviewers are chosen based on the equipment, skills, and
interests they have listed but there may be some mistakes in
assignments), you will be left at the head of the queue. This means you
should get the next package that matches your equipment and areas of
interest.
Record Your Work
----------------
A crucial part of the review process is recording what you do. You
must make complete and accurate notes of your time spent working on the
package. Don't rely on your memory to record the problems or
suggestions you come across, because you will forget quickly as you
move on to other things. So, the first thing to do when you get a
submission is to start documenting everything that happens. Since you
will probably be working on several machines, you may have to work with
pencil and paper (gasp).
Evaluating the Format of the Submission
---------------------------------------
Was it in the form of a "shar" file, or similar packaging appropriate
for the architecture?
Did in unpack correctly?
Did it unpack in the places you expected it to?
Evaluating the Description and Purpose
--------------------------------------
Is there a README file that contains:
- the purpose and value of the software (give details here)
- the types of systems it is intended for (e.g., BSD only,
Unix and DOS, etc.)
- any dependencies in the system (e.g., must have perl to
run)
- known limitations of the software
- the authors of the software (with e-mail addresses)
- the "patchlevel" of the software (see below)
- any copying or distribution conditions
Is there a "patchlevel.h" file (or equivalent) indicating the version
number of the software?
Building the Software
---------------------
Is there an Installation document explaining how to build the software?
Are the options and conditional parts of the package (e.g., do this for
DOS, this for System V, etc.) clearly documented?
Is there a proper Makefile? (Imakefile for X software?)
Did the make run correctly?
Are building and installation two separate steps?
Did the software build on each of the architectures you were able to
test? (Give details about your testing environment.)
Testing the Software
--------------------
Did the software run on each of the systems you tested?
Did the program perform the functions it was supposed to perform?
It is not your place to fix the software you are reviewing. However, if
you find a problem with an obvious solution, make sure you document it
so the authors can make use of it.
The Documentation
-----------------
The documentation is a very important part of a submission, so it
should be reviewed carefully. The documentation may be built-in to the
program and be in the form of document files and/or man pages. It is
difficult to give simple rules for documentation, and not all programs
require the same amount of documentation, but here are some things to
consider.
General Guidelines
------------------
Is the documentation written in a form that is clear, precise, and
easy to understand?
Is each feature or function of the program documented?
Is the documentation organized? Sections and sub-sections often
make documents easier to read and understand.
Documentation should be provided in "text only" form. An author may
choose to also provide formatted manuals that use PostScript or TeX,
but a readable form should be provided.
Guidelines for Unix Documentation
---------------------------------
Is there a man page? Man pages should contain the following
sections (at least):
NAME required
SYNOPSIS required
AVAILABILITY optional
DESCRIPTION required
OPTIONS required if there are any command-line options
ENVIRONMENT required if there is provision for environment
variables
FILES required if use is made of other files
SEE ALSO optional
DIAGNOSTICS required if the program can produce debugging output
NOTES optional
BUGS required if any are known
AUTHOR optional
These sections should be complete (e.g., all the OPTIONS must be
described).
Guidelines for VMS Documentation
--------------------------------
Is there a VMS HELP file? HELP files should contain the following
sub-topics (at least):
Parameters if there are any
Command_Qualifiers if there are any
Examples if appropriate
Is there additional documentation to supplement the VMS HELP file?
Guidelines for DOS Documentation
--------------------------------
There are no standards for DOS documentation, and this makes the
review process difficult. We suggest that the information and
features described above should also be present in DOS
documentation, although they may not be in the form described
above.
Functionality and Features
--------------------------
Does the software perform some function that is valuable?
Are there obvious features or additions that would improve the package?
Overall Evaluation
------------------
What is your overall evaluation -- would you recommend it to a friend?
Would you suggest that this submission:
- be accepted for posting as is
- be accepted after minor revisions (that you have detailed)
- be returned to the author with a recommendation to make
major changes and re-submit
- be rejected
Submitting a Summary
--------------------
The final step is to return a summary to the moderator. Please make
sure you quote the "reference name" in your summary, preferably in the
subject line.
DO NOT send your summary to the author. The moderator will collect
all the reviews, prepare a grand summary, and forward it to the author.
Your summary should provide as much detail as possible. Make sure you
give details on the kinds of machines you tested on. You may choose
to use this file as a template to record your review.
If you are recommending that a submission be posted, you should also
provide a short summary that would be appropriate for publication with
the software. This summary might mention why you found the package
useful, what you liked about it, what machines you tested it on, and
what limitations you did find. Your name will not be attached to this
review summary when it is returned to the authors or posted.
Contacting the Authors
----------------------
Your identity will not be revealed to the authors unless you choose to
do so. If you feel that you would like to contact the authors for
clarification, you may contact them directly or ask the moderator to
forward your question. You should only contact the author for
clarification or additional information needed to complete your
review. You should not comment on the submission at this time, but
instead save your comments for the report you send to the moderator.
You should also ensure that your interactions with the author are
conducted in a courteous and professional manner.
In addition, you should ensure that the other reviewers working on that
submission also receive the information you get back from the authors.
Further, you must do so in a manner that does not interfere with their
wishes not to identify themselves to the authors.
It is not a good idea to suggest that authors make patches to software
during the review process. If you find a problem that the authors are
able to fix easily, document the problem and suggest that minor
revisions are needed before the submission is posted. It is important
that you are not evaluating software that has been patched, while others
are working with the original submission.
You should not send the author any comments about, or evaluation of, the
submission. That information should be sent to the moderator in your
final summary, and he will collect the comments from all the reviewers
and forward them to the author if appropriate..
--
Andrew Patrick acting as Comp.Sources.Reviewed Moderator
Department of Communications, Ottawa, CANADA
csr at calvin.doc.CA
More information about the Comp.sources.reviewed
mailing list