This issue contains two highly technical papers on fault prediction and model checking. Non-negative sparse-based SemiBoost for software defect prediction, by Tiejian Wang, Zhiwu Zhang, Xiaoyuan Jing, and Yanli Liu, presents a novel semi-supervised learning technique to predict where faults could be in software. (Recommended by Giuliano Antoniol. Past-Free[ze] reachability analysis: Reaching further with DAG-directed exhaustive state-space analysis, by Ciprian Teodorov, Luka Le Roux, Zoé Drey, and Philippe Dhaussy, presents a new algorithm to perform reachability analysis in model checkers that significantly reduces the state-space explosion problem. (Recommended by Ronald Olsson.)
In a previous editorial, I set out STVR’s policy on extending conference papers to journal submissions . The major requirements are that the journal version must have at least 30% new material, the journal version must include a citation to the conference paper, and the journal version must discuss the conference paper and summarize the new material. Here I suggest some practical guidelines for how to do the extension.
The extension should start with four broad changes:
If the same title is used, then you would have two papers with the same title. That is confusing to everybody who reads or references either paper. If the same abstract is used, then no reader (reviewer or otherwise) will believe the journal submission is different. Don’t just add a few sentences, rewrite the whole thing!
It might be possible to just have one of (3) or (4), not both, but from my experience, it would be very hard to get that past the reviewers. Many times I have seen papers extended with only a new idea, and the reviewers almost invariably require an empirical evaluation (major revision). Likewise, if a paper extends the experiment without adding a new theory or idea, the reviewers are very likely to respond by saying “nothing new, reject.” That is, a stronger experiment (more subjects, more rigorous analysis, etc.) may increase our confidence in the conclusions, but if the conclusions are unchanged, it’s very hard to convince the reviewers to publish the new version.
Several other things should be changed as well. I suggest throwing out the old introduction, outlining a new introduction, and then writing it completely. Again, if the reviewers have read the introduction before, you are almost asking them to reject the paper on the basis of not enough new material.
Add additional related work. Add a lot of additional related work! Conference papers are almost always limited to 8 to 10 pages, and we often make our related work section as short as possible to leave room for the “good stuff” (our ideas). With a journal version, you have much more space to write, so use it. Journal reviewers are much more likely to criticize not having enough references than having too many references.
Add more examples and explanations. Add more data in the form of tables and figures. Reflect on all the hard decisions you made when forcing the conference paper into a small box, and put some of that material back in. The editor or reviewers will do a side-by-side comparison of the conference and journal papers. You want it to look as if the conference paper was the primitive or immature version, and the journal paper is all grown up. You emphatically do not want the journal version to look like the same paper with a few sentences added here and there.
Finally, rewrite everything. Clean up the writing, polish the sentence structure, check the grammar and punctuation again, and edit, edit, edit. My favorite writing teacher told me there are no great writers, just great editors.
I want to thank Rob Hierons for discussions leading to this editorial, and many students for helping me refine these suggestions. Jeff Offutt. STVR Policy on Extending Conference Papers to Journal Submissions (Editorial), Wiley’s journal of Software Testing, Verification, and Reliability, 26(4), June 2016.
George Mason University
4 October 2016