puter deployments.

Imagine how different OLPC implementation would be if it were instead conceived as “one laptop per teacher.”

Julian m. Bass, addis ababa, Ethiopia

Refocus fragmented cs
conference culture

Moshe Y. Vardi was brave (and absolutely right) in taking on CS conference culture in his Editor’s Letter “Conferences vs. Journals in Computing Research” (May 2009). Consider how a new technique develops: Prof. Fragment has an idea and publishes it at a workshop. Several of his students refine and modify it over the next few years, publishing their work in various conference proceedings. Another of his students iden-tifies a crucial application of the work. Finally, Prof. Fragment gives an invited lecture at a major conference, covering the full story supplemented with compelling empirical evidence. Unfortunately, the lecture is not accompanied by a paper. Now everyone wants to use the powerful new technique, asking Prof. Fragment for permission to spend a sabbatical term with him at Jigsaw University. He is able to accommodate only one old pal, while everyone else makes do with his group’s five conference papers and the online slides of the invited talk. This typically consists of more than 100 pages of material with overlaps, omissions, and contradictions, because each paper represents a different stage of the overall work.

Prof. Fragment would do the CS community a service by publishing his technique in one coherent journal article, presenting the method, together with refinements, applications, and empirical results. But if he were to write such a paper, some referees would likely recommend rejection on the grounds it contained nothing new.

Lawrence c. Paulson, Cambridge, England

 

Begin with an Author’s Response to Reviews We agree with Ken Birman’s and Fred B. Schneider’s Viewpoint “Program Committee Overload in Systems” (May 2009) regarding the shortcomings of the conference-review system. A key factor is the lack of incentives for authors to submit their best possible papers,

leading, as Birman and Schneider described it, to yet more submissions, along with larger program committees to accommodate them, overworked volunteer program-committee members, and less-informed decisions, as these members are able to read only a small percentage of all submissions.

To discourage repeated submission of the same manuscript—often unchanged —to many different conferences, we propose a simple solution: require that all conference submissions provide two things:

History. A review history of the submission that includes the previous venues to which it was submitted, along with the submitted versions and the reviews the authors received; and

Summary. An explanation of how the authors addressed the concerns cited in previous reviews.

This approach would allow program committees to build on the expert knowledge of the previous review committees where the level of expertise might have differed from their own. Broadly used, it would reinforce the argument that publishing in a CS conference is like a journal publication in other disciplines. It also means authors are further motivated to address or rebut the concerns cited in previous reviews, resulting in a better understanding of the concerns. Finally, authors would be discouraged from “shopping the paper around” until it meets the bar of a particular program committee, encouraging them instead to prepare an acceptable manuscript before its initial submission.

Though this requires extra work by authors at submission time, that work is worth the benefit ultimately received. The concern that some authors might not disclose previous submissions can be addressed the same way simultaneous submissions are treated—by clearly stating the policy and consequences for violating this trust.

Changing the existing system is not difficult. All it takes is one program-committee chair doing an experiment. If it’s a good idea and works, others will follow. If not, it will get everyone thinking about alternatives. Using an author’s response to reviews is a recent innovation but is already widely used in the CS community.

Jose nelson Amaral,

Edmonton, alberta, Canada michael hind, Yorktown Heights, n Y

name the field: computer
or computing

The words we use to describe things profoundly affect how we think about them, and once a term has gained a foothold in a field, changing it and its effects is nearly impossible. An example is Peter J. Denning asking “What is computer science?” in his Viewpoint “Beyond Computational Thinking” (June 2009). It has always seemed strange to me that we call our field “computer science” rather than “computing science,” focusing our attention on the hardware and its design and programming rather than on the higher-level great principles that are in fact independent of hardware and historically part of other scientific disciplines.

Perhaps we should change our titles and business cards to read “computing scientist” from “computer scientist” to emphasize this point.

harry J. foxwell, McLean, va

Author’s Response:

I endorse Foxwell’s view of “computing science.” Old names stick when they establish a brand that people generally like. That seems to be the case for “ computer science,” a name established by the founders of the field in the 1950s. At that time, people in computationally intensive application areas (such as physics and statistics) called what they did “computing science,” but the computer scientists of the day felt that “computing” represented applications and not the central focus of R&D. In the 1980s, we began using the term “ computing” in place of “computer science and engineering.” Twice in ACM history some members proposed calling the organization the Association for Computing, but the required constitutional amendments failed, probably because the voting members liked the long-established brand name. Today, ACM goes by the motto “Advancing Computing as a Science and Profession.” We’re getting there.

Peter J. Denning, Monterey, Ca

Communications welcomes your opinion. to submit a letter to the editor, please limit your comments to 500 words or less and send to [e-mail].

© 2009 aCM 0001-0782/09/0800 $10.00