|
|
|
|
CR
WRITING GUIDELINES |
|
Download
PDF version of Guidelines |
|
Over the past few years, Computing Reviews (CR)
has gone from publishing 40 reviews to 150 to 200 reviews per month.
Now that we have increased the number of items being reviewed, we
want to make CR more interesting to read. The reviewer’s role is to
write interesting reviews that summarize and assess the item being
reviewed.
In order to raise the standard of the reviews we publish, we’ve
come up with seven primary points and a checklist. Ideally, reviews
will address all of the primary points below. At a minimum, each
review should at least touch on most of them.
1—Accuracy: Please be sure your review is technically
accurate.
2—Assessment: Your opinion of the item should
be given. This does not need to be an explicit statement. In some
cases, your opinion is implied by the tone of the review, and in
others, it is specifically stated.
3—Thesis and Context: You should summarize the
central ideas and supporting points of the item concisely and clearly.
A framework for the topic of the item should be provided. This should
give some background on the topic, describe the current state of
the field, how the particular topic fits into the area as a whole,
and why readers should care about it. If the item is about an area
of computing with which not many people are familiar, you should
at least explain the topic and why it is important to the field.
4—Interesting: At a minimum, the review should be
interesting to the item’s intended audience. It would be even better
if it was also interesting to a broader audience. Not every review
will be accessible to every CR reader, but we would like
the reviews to be accessible to as broad an audience as possible.
Some specific ways in which you can make the review more interesting
to readers include: identifying whether the idea presented is novel
or provides a new perspective on the topic, stating whether the topic
of the item being reviewed is applicable to real-world situations,
putting the item in context and comparing it with other items in the
field, and providing concrete examples of where the item succeeds
or fails.
5—Timely: The item being reviewed should cover
a timely topic. In most cases, the publication date will be very
recent. In other cases, the item being reviewed may be older, but
should be relevant to today’s readers.
6—Well written: The review should be well written,
organized, and free of typographical and spelling errors. Your points
should also be clear.
7—First lines: The first one or two sentences
of the review should capture the essence of the review, because
these sentences will be displayed prominently throughout the site.
Use your introduction to draw readers in with a brief statement
about what the work’s overall focus is, or about its relevance with
respect to current developments in the field, to related areas,
or other comparable works. If at all possible, the review should
not begin with "this book" or "this paper." |
|
OTHER POINTS YOU MAY WANT TO INCLUDE IN YOUR REVIEW: |
|
• Summary and opinion: Summarize the work and
give your opinion of it. (For some books, you may wish to include
chapter-by-chapter coverage.)
• Presentation versus ideas presented: Make a clear
distinction between your views on the topic and your assessment of
the author’s presentation of the topic.
• Basic purpose of the work: State whether it is
a tutorial, research, a survey, or textbook with examples, to name
a few. Does the work achieve its intended purpose? If applicable,
are exercises included and adequate? Is the item a revised edition?
If so, how does it compare with previous editions?
• Audience: Who is the intended audience, user,
or reader? What (if any) specific background is needed to understand
the material?
• Overall evaluation: Give your overall evaluation
of the work. What are the best and worst features? Would you buy it,
recommend it, use it, treasure it?
NOTE: There is no prescribed writing style. For
guidance, follow Strunk and White (The Elements of Style).
CR editorial staff may edit reviews using The Chicago
Manual of Style when improvements in grammar and form are required
for publication. |
|
EXAMPLES OF BEST REVIEWS |
|
To get a feel for the style and format you want to
achieve in writing your review, and to become familiar with CR’s
editorial philosophy, it’s best to read reviews published in past
issues of CR. Examples follow to give you an idea of what
we’re looking for in a review.
Consider how the review would be useful to readers. What information
would they expect to see if they were reading a review? Readers will
want to know if you think the item is worth spending time or resources
on.
To get a feel for the style and format we are looking for, please
take a look at these examples of various types of reviews:
Books:
1--B. Beizer’s review of Measuring
Computer Performance: A Practitioner’s Guide
[Review #: CR126187]
-Provides a good balance of the book’s strengths and weaknesses. Negative
comments are o.k.
2--Mohammed Guller’s review of Modern
C++ Design
[Review #: CR126125]
-A good example of a review that explicitly and thoroughly states
what audience might be good for the book.
3--Ramanathan Guha’s review of Web
Services: Building Blocks for Distributed Systems
[Review #: CR126127]
-Good at setting the book in a context--mentioning that it is not
as up-to-date as some other books on the same subject. Also good at
defining the audience for the book.
4--Thomas Sheehan’s review of Algorithms
in C++, Part 5
[Review #: CR126184]
-Compares the book to previous editions and places it in the context
of developments in the field.
Articles and Proceedings Papers:
1--Baohua Wang’s review of "A
Differential Equation for Placement Analysis"
[Review #: CR126191]
2--D.B. Lange’s review of "Covariance
and Contravariance"
[Review #: CR119384]
-Both provide not just a summary, but a critical evaluation.
Whole Proceedings:
1--Claire Vishik’s review of XML
Security
[Review #: CR128709]
-Provides a strong introduction and conclusion, and thoroughly covers
the individual papers within the proceedings volume.
Comparative Reviews:
- Graham Jenkins' comparative
review on Linux books from 1998
[Review #: CR128709]
- H. Van Dyke Parunak’s comparative
review of works in quantum computing
[Review #: CR126337]
|
|
EDITORIAL POLICIES |
|
• Plagiarism: According to the ACM’s Policy on Plagiarism:
Respecting intellectual property rights is a foundational principle of the
ACM’s Codes of Ethics. Plagiarism, in which one misrepresents ideas,
words, computer codes or other creative expression as one’s own, is a
clear violation of such ethical principles. Plagiarism can also represent a
violation of copyright law, punishable by statute. Plagiarism manifests
itself in a variety of forms, including
- Verbatim copying, near-verbatim copying, or purposely
paraphrasing portions of another author’s paper;
- Copying elements of another author’s paper, such as equations
or illustrations that are not common knowledge, or copying or
purposely paraphrasing sentences without citing the source; and
- Verbatim copying of portions of another author’s paper with citing
but not clearly differentiating what text has been copied (e.g., not
applying quotation marks correctly) and/or not citing the source
correctly.
It is unacceptable to engage in any form of plagiarism. If we find that a review has
been plagiarized, the reviewer will be removed from our reviewer list, and his or her
reviews will not be published. You can read the entire ACM Policy on Plagiarism here:
http://www.acm.org/pubs/plagiarism_policy
• Conflict of interest: Because we
want our reviews to be objective, please do not review any items that
you wrote or edited. In addition, do not review items from a publication
you are involved with (i.e., one you sit on the editorial board of),
or items written by friends.
• Direct contact with author(s): We discourage you
from contacting the author(s) of the item you review prior to publication.
This can compromise your objectivity.
• Vendor- and product-specific publications: Our
policy is to avoid reviewing vendor-specific and product-specific
manuals, or how-to books and magazines.
• Advance notice of publication: We cannot tell
reviewers when their reviews will appear prior to publication. However,
once the review has been published online, you will receive a notification
email.
• Editorial Discretion: CR is under no
obligation to publish any given review, and reserves the right to
exercise editorial discretion in that regard.
|
|
FORMAT
& SUBMISSION GUIDELINES |
|
Additional help can be found at http://www.computingreviews.com/reviewer/
by clicking on the ? tab.
Selecting Material to Review:
- Reviews you have selected from the system:
In the Reviewer’s Area, you can search the system for items to review,
and click the box next to any item you wish to assign yourself to
review. This generates a Current List of items for review. The system
allows you to work on only one review at a time, but you can save
the others to your Wish List to review later.
- Reviews you have been assigned by the Assignment Editor:
You will first be queried via email as to whether you are interested
in reviewing an item. The email message will contain a URL, which
will take you to a screen for the item, where you can respond Yes
or No. If you answer Yes, you will receive a second email confirming
receipt of your response, and you will be directed to the URL of
the Web form where you can write your review of the item.
Submission via Web:
In the Reviewer’s Area, you can write, edit, preview, and submit
your reviews using the Computing Reviews Web interface. When you begin writing
your review, the screen will be labeled Latest Version. The review
writing area is a free-text box in which you can type the review or
paste text copied from a file created in another program, such as
Microsoft Word. Delete the default text [[Begin Your Review Here]],
and begin writing.
The Reviewer screen includes links to the Writing Guidelines and
Writing Tools for general technical writing help. In addition, you
can click on Special Character Sets for a menu of science and mathematical
symbols to use in your review, if necessary. An Add New button allows
you to cite one or more references at the end of your review.
Click PREVIEW to see how the Latest Version of your
review will appear when published on the Web. Click BACK
if you want to make any changes before submitting the review.
Click SAVE CHANGES when you are done writing. This
is saved as the Latest Version, and is the version the CR
editors will see. When you have previewed the Latest Version and are
ready to submit the review, click SUBMIT to see one
last preview screen; examine your review carefully and, if you are
satisfied, click CONFIRM SUBMISSION. You will see
the following confirmation message: ”Thank You for submitting your
review below. Please print or save this page for your records.”
Review in Progress: You can save a partially written review and return
to it later. Clicking the WRITE button in the Reviewer’s
Area will take you to the Latest Version, the last version you saved
before quitting. You can then write, edit and submit, following the
steps above.
Submission via Email:
We prefer that you submit your review via the CR
Web site. As an alternative, you can send it via email in plain ASCII,
or as a Microsoft Word, LaTeX, TeX, or txt attachment, to newreviews@computingreviews.com.
Category Changes:
Check and correct the editor-suggested ACM CCS categories and general
terms. Click on the CHANGE CCS button to send a note
about category changes. If you are emailing the review, include the
category changes at the top of the file.
What Happens Next?
The CR editorial department will advise you of receipt of
your review, and will send it to a CR category editor for
preliminary approval. It may be edited for clarity and length, as
well as for obvious errors of grammar, spelling, and syntax. You will
be consulted only if the editing suggested by the category editor
or the CR staff is very substantial.
Author’s Rebuttal Privilege
The CR rebuttal policy allows an author to respond to a review
of his or her work. The policy stipulates that the reviewer may choose
to write a re-rebuttal in response to the author’s rebuttal. The author
will then have an opportunity to read the re-rebuttal, and may either
withdraw the rebuttal (in which case neither will be published) or
proceed, in which case they will be printed together in CR.
If the reviewer decides not to write a re-rebuttal, only the rebuttal
will be published. We ask that both author and reviewer limit the
length of the rebuttals to that of the review itself; that the rebuttals
address substantive issues; and, of course, that both parties refrain
from making ad hominem comments.
|
|
CHECKLIST FOR WRITING REVIEWS
|
|
The best reviews will address all of the primary points below. At a minimum, each review should at least touch on most of them.
Each review should address most of the following primary points:
— Accuracy: Is your review technically accurate?
— Assessment: Did you give your opinion of the item? If the item is a paper, did you
consider these questions: Does the item address an important problem? Is the
solution proposed novel? Do the authors substantiate the claims made in the paper? Is
the paper’s methodology sound?
— Thesis and context: Did you summarize the central ideas and supporting points of
the item concisely and clearly? Did you provide a framework for the topic of the item
being reviewed? This should give some background on the topic, describe the current
state of the field, how the particular topic fits into the area as a whole, and why
readers should care about it. If the item is about an area of computing with which not
many people are familiar, did you at least explain the topic and why it is important to
the field?
— Interesting: Did you try to make the review interesting to the item’s intended
audience, as well as a broader audience? Did you identify whether the idea is novel or
provides a new perspective on the topic? Did you indicate whether the item being
reviewed is applicable to real-world situations? Did you provide context for the item or
compare it with other items in the field? Did you state the item’s successes and
failures?
— Timely: Is the item about a timely topic? Was the item published recently? If it’s a
review of an older item, did you discuss how it fits in with recent developments in
computing?
— Well written: Is your review well written, organized, and free of typographical errors?
Are your points made clearly?
— First lines: Do your first couple of sentences capture the essence of the review and
draw readers in with a brief statement about what the work’s overall focus is, or about
its relevance with respect to current developments in the field, to related areas, or
other comparable works? Does your review begin with words other than “this book” or
“this paper”?
Most reviews should also address these additional points:
- — Audience: Did you indicate the intended audience/user/reader, and what (if any)
background is needed?
- — Purpose: Did you indicate the basic purpose of the material? (Was it a tutorial,
research, survey, or textbook with examples?)
Please also check:
- — CCS and General Terms: Are the CCS and general terms assigned to the item
correct as is, or should they be changed? Did you enter your corrections?
- — Length: Is the length suitable for the review? (Article or chapter: usually 100-250
words; Book: usually 250-800 words)
|
|