Editorial:
How to Become an STVR Reviewer

This issue has an eclectic collection of papers. The first, Error-preserving local transformations on communication protocols, by Kapus-Kolar, presents theoretical results on communicating state machines, proving error-preserving local transformations to support reachability analysis. (Recommended by Lu Zhang.) The second, An Automated Analysis Methodology to Detect Inconsistencies in Web Services with WSDL Interfaces, by Fisher, Elbaum, and Rothermel, presents an analysis technique that finds inconsistencies in definitions of web services. (Recommended by Sudipto Ghosh.) The third, A Test Purpose Based Approach for Testing Timed Input Output Automata, by En-Nouaary, describes a technique to test real-time properties of software, as modeled in timed automata. (Recommended by Byoungju Choi.) The fourth, Reliability Assessment Based on Hazard Rate Model for an Embedded OSS Porting Phase, by Tamura and Yamada, offers a software reliability assessment for embedded open source software. (Recommended by Tor Stalhane.)

I occasionally get email messages from young scientists asking how to become a reviewer for the journal, so I am summarizing some of my responses here. First, it's wonderful that people want to help because the journal always needs good reviewers. I often use the phrase "good journals need good papers, but it's the reviewers who make a journal great!" I mean that with great sincerity. Reviewers provide the filter so that readers can pick up a paper expecting it to have quality research. Without that filter, we would all need to read dozens of papers to find one gem.

As co-editor in chief, I don't assign very many papers to reviewers. The reviewing editors on the editorial board handle most reviewing assignments. Being invited to review a paper is a social process, and here are a few ways to become part of that process:

• Establish a positive reputation with members of the editorial board. I can't emphasize enough how important it is to meet people at conferences. Your biggest exposure in the testing area, of course, is ICST, but testing researchers attend many conferences. Most reviewing editors ask people they know because personal contacts are more likely to provide good reviews in a timely fashion.
• Part of your advisors' job is (or was) to help you meet people in the field. And by the way, the most unproductive behavior at conferences is to spend all your time with students and young scientists that you already know. You have to meet senior members of the community.
• Publish in STVR. We always look for authors of papers in the journal when finding reviewers.
• If you are invited to be on a technical program committee, do your best to impress the PC and other TPC members. Write good reviews, energetically join the discussions, and try to make sense. Journal papers are usually longer, and journal reviews are expected to be deeper and more thoughtful, but senior people in the field will note the quality of your conference reviews and invite those who do a good job to review journal papers.
• Write really high quality reviews in a timely fashion. If your first few reviews are short and not helpful, people will stop asking. If you do a good job, people will ask more often. (Eventually enough so the invitations may become a burden!) One responsibility of a PhD advisor is to teach students how to write good conference and journal reviews.
• Publish publish publish. When a reviewing editor gets a paper on topic X, a common strategy is to search the web to see who else is publishing on that topic. You want your name to come up on that search.

I previously wrote two essays: "Standards for reviewing papers" and "Why should I review papers?" These are posted on my STVR editor's website (http://www.cs.gmu.edu/~offutt/stvr/) and will help inexperienced reviewers.

Jeff Offutt
offutt@gmu.edu
30 November 2012