Upgrading a SIG Newsletter: One Editor's Experience
by Craig Partridge, SIGCOMM Newsletter editor (1988-1991)
Two years ago, when I became editor of SIGCOMM's Computer Communication Review (CCR), the newsletter was issued about three times a year, on an slightly irregular schedule, and printed about 100 pages (5 papers) a year (not including the annual SIGCOMM conference proceedings). This year it will print about 500 pages and about 20 papers plus book reviews and small research notes. The goal of this essay is to try to explain how that happened. I say "try" because even though I succeeded in improving the newsletter, I'm not entirely sure which of the several tactics tried were most effective.
One important advantage I had when I started was that CCR was already a respectable, if slightly neglected, newsletter. Its editors had historically been relatively senior people in the field of computer communication and they had refused to print work they considered poor. At the same time, these editors were often busy, and made the newsletter a low priority. As a result, the newsletter was issued irregularly and little effort was made to recruit papers. The editors simply reviewed what was received.
When I took on the position of editor, I started with three major goals:
- Issue the newsletter on a regular schedule and publish the schedule. The goal was that everyone should know when to expect their issue of CCR, and that authors should know roughly how soon their paper would be issued (CCR has tried to print within 3 month of receipt).
- Increases both the number and diversity of papers published. My predecessor, John Burrus, had told me he felt the newsletter attracted too few papers. He also noted that the range of papers received was limited.
- Improve the appearance of the newsletter. CCR was still being issued with the industrial green covers and the copy was offset printing of photocopies. I felt improving the look of the newsletter would convey a more professional image.
There were also some features of the newsletter I tried hard not to change:
- Timely publication. I wanted to try to keep publication quick. I felt CCR could make a major contribution as a prompt way to get ideas out into the community.
- Ease of publication. While CCR has historically rejected poor work, it has also tended to take interesting work which was not as polished as journals would require. As a result, it has been a good place for publishing new ideas, and for new researchers to break into print. I view that as a very important service that CCR provides.
To achieve these goals I did a few things. First, I set strict publication deadlines for myself. CCR was to be sent to ACM on the 15th of the month prior to the publication date (so September 15th for the October issue). Furthermore, I promised myself that I would send in an issue with as much or as little material as I had in hand that date--even if that meant a smaller than normal issue. Second, I began buttonholing colleagues at conferences and meetings, asking them to write up their talks for CCR. Third, I went digging into recent technical reports that I found interesting but had not been published, and asked their authors if I could publish them in CCR. The initial result was a modest number of papers, but more than enough to satisfactorily fill the first few issues. The fear of having to issue an embarrassingly small issue, kept me hunting vigorously for papers, and after about nine moths it paid off--in the summer of 1989 I received two issues worth of submissions in less than two months.
At the same time, the SIG chair, Vint Cerf and I started tinkering with the cover. The first change was to get red colored cover which simply said "Computer Communication Review" on the front. That cover lasted for two issues. SIGCOMM members reported that they liked the idea of the new cover, but missed having the table of contents on the cover. Also the second issue with the new cover was large enough (128 pages) that the binding was square, and several members asked if we could put the issue number and date on the spine of the issue. To meet these concerns, Dr. Cerf hired a design expert to develop a new cover. The new cover has space for a selected table of contents and has issue information on the spine. Members appear to be happy with the new format.
I also tinkered a bit with how the newsletter was put together. I now ask authors for Postscript via e-mail instead of hardcopy. I then print these papers on high quality layout paper in my laser printer (Hammermill LaserPlus paper--it works it any regular laser printer) and run a small program to have the laser printer number the pages for me. The result has been an improved print quality which I believe improves the look of the newsletter.
Finally, we work hard to keep authors happy. Every CCR paper gets at least one, and often two or three reviews. We try very hard to get reviews to authors within three weeks of receipt of the paper, and emphasize reviews that improve the paper (rather than accepting or rejecting, which is a decision I alone make). CCR authors also get 6 complimentary copies of the issue in which their paper is published (a practice I inherited from John Burruss). The result appears to be happy authors--several authors have published more than one paper in CCR.
In retrospect, it is hard to be sure what features made the most difference. Personally, I suspect the key changes were (1) regular schedule, (2) improved appearance, and (3) keeping authors happy. Hustling for papers for a few issues also seems to be important (we now can rely on submissions and no longer have to hustle, though I still pursue people after interesting talks).
SIG Editors Manual
Updated November 1993
ACM Queue’s “Research for Practice” consistently serves up expert-curated guides to the best of computing research, and relates these breakthroughs to the challenges that software engineers face every day. This installment of RfP is by Anna Wiedemann, Nicole Forsgren, Manuel Wiesche, Heiko Gewald, and Helmut Krcmar. Titled “The DevOps Phenomenon,” this RfP gives an overview of stories from across the industry about software organizations overcoming the early hurdles of adopting DevOps practices, and coming out on the other side with tighter integration between their software and operations teams, faster delivery times for new software features, and achieving a higher level of stability.
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.