Refereeing, Formal Reviewing, and Reviewing
Summarizing the Differences Between Refereeing, Formal Reviewing, and Reviewing:
Refereeing follows a defined process and is based on criteria of originality, correctness, novelty, importance, and clarity of exposition. "Defined process" for refereeing means: The editor send an article to a fixed number (usually 3) independent referees.
Each referee prepares a detailed evaluation of the manuscript, which is then communicated anonymously to the author. The author almost always rewrites; the article is sent back to the original reviewers for final acceptance or rejection. This process usually takes 6 months to a year, often longer. Because of the depth of evaluation, followed by the refinement of rewrite, it is rare that this process can take place in less than 6 months.
Formal reviewing also follows a defined process, similar to that of refereeing, but the criteria of originality, novelty, and importance are not required. The length of time for processing is usually shorter (2 to 6 months) since both evaluation and rewrite (if one is done) are based on fewer criteria.
Reviewing does not necessarily follow a defined process or set criteria. Its primary objective is independent assessment; formal reports do not have to be written by the reviewers, i.e., the review can be oral.
Refereeing is applied to all articles published in the primary journals (CACM, Journal, and the Transactions not Computing Surveys because the material, in general, is not originalÙ). Formally reviewing and reviewing are the evaluation processes usually applied to conference proceedings.
To know exactly how to categorize our proceedings, we would need to study the procedures and criteria for each, an onerous task not necessarily needed. For the time being, I think it is safe to say that although some of the proceedings may be refereed as defined above, most are formally reviewed or just reviewed. Speaking about ACM proceedings as "refereed" is probably misleading.
SIG Editor Manual
Last Update November 1993
Written by leading domain experts for software engineers, ACM Case Studies provide an in-depth look at how software teams overcome specific challenges by implementing new technologies, adopting new practices, or a combination of both. Often through first-hand accounts, these pieces explore what the challenges were, the tools and techniques that were used to combat them, and the solution that was achieved.