During the past few years, I (co-)authored and reviewed a lot of research papers, from workshops to journals. By being on both sides of the table, here are some editorial tips that I’d like to share on writing a convincing (Computer Science / Web Technologies) research paper, and hopefully getting it accepted (don’t blame me if it’s not!).
Before starting, there are a few things that every student should know about the process:
– First, and that’s the law (game?) of blind-peer-review, you don’t know who reviews your paper. This means that the reviewer can be a super-busy professor who’ll make a decision in 2 minutes just by reading your abstract, or a pedantic junior researcher complaining that you don’t cite his poster presentation at yet-another-unknown-workshop. Hopefully, reviewers are generally careful researchers taking time to properly read the paper, make an opinion based on your research and their knowledge of the topic. In this case, even if the paper is rejected, you should end-up with a useful review that will let you improve the paper for the re-submission, so don’t be upset.
– Then, keep in mind that your conference/workshop paper (journal are different) will not be the only one assigned to the reviewer for this event. In some cases, reviewers are assigned up to 10 papers; here, reviews are generally spread among colleague or students – and the main reviewer should ensure that the quality of reviews is OK. But even by delegating, a reviewer could have to read 5+ reviews. So, your paper must catch the attention of the reviewer, and stand out of the crowd. Are you aware of the 5 seconds rule for websites? There’s something similar for research papers: you have to wow the reviewers/readers since the abstract. Personally, I have a first feeling about a paper on the first minute reading it (e.g. compelling abstract with clear contributions VS topic that has been discussed 10+ times in the same venue, etc.). While reading the full paper is what makes the final decision, the first impression counts and can influence the decision.
– Write a compelling abstract and introduction. Convey a “WOW!” effect the the reviewer, rather than a “OK, yet-another-paper on …”. This means: clearly identify the problem, the gap in the state-of-the-art and your contribution. If you can do that in a paragraph, you’ve done the hard part of the job: giving the reviewer an incentive to carefully read your paper. And you’ve showed that you can clearly articulate your research in just a few sentences.
– If your paper describes some kind of software, include at least screenshots and – unless that’s something confidential – links to a demo, source code or video. Show that you’ve really done what you promise in the paper, and that it’s not just vaporware. It doesn’t need to be a super-fancy system with bullet-proof source-code (at least if you’re in academia, that’s just a research prototype), but it shows that the conclusion of your experiments (or the experiments themselves), are based on something concrete. Oh, and make sure that the links work during the review process (no 404 please).
– Show that your research matters and that it’s a problem worth solving. That should be in the intro, by using references of related scientific work but also to general reports (e.g. studies by mainstream media, business reports, etc.). That’s particularly true for competitive events that value practical research with real-world impact. If you can show that your research can solve large-scale problem (not CS problem, but general issue where CS is just a means to an end, e.g. environment, policy, etc.), that’s great.
– Make sure that any pictures / screenshots print well on black and white paper (unless, hmmm, you’re ready to pay for the journal extra costs). Make sure as well that their text (depiction, legend, etc.) can be properly read on the printed version, and ideally do not require to zoom the PDF. And if you’re writing your paper/figures using Word, make sure that the red-underlined text that the spell-checker hadn’t recognised doesn’t appear in your submission!
– Chose which side of the Atlantic you are, i.e. decide if your paper uses UK english or US english. You know: centre vs center, personalization vs personalisation etc. There may be some guidelines by the chairs/editors, so check those before your submission, in addition to other stylistic requirements (uppercase on titles, etc.). That’s a bit pedantic, but that shows that you care about all the details.
– Check the references. Especially, be sure there are no typos in the authors’s names, nor paper titles, etc. As the previous point, that seems minor, but that showcases how much precision you attach to details, and how precise and accurate you are in your overall article. A bibliography done at the last-minute/full-of-typos is generally not a good sign. If your BibTeX file is properly done, that should not be an issue, though.
– Adapt to your audience. If you were going to a party, would you explain your work/research the same way to a buch of geeks or to some MBAs? Probably not, and the same rule apply when writing a paper. Know the community/event you’re targeting and adapt the paper accordingly. That could mean explaining some acronyms that are obvious in a community but not in another one, adapting the background section (e.g. do not explain Linked Data if you’re submitting to LDOW, but do so for a general CS-Web conference), etc.
– Finally (easier said that done): wait one or two days between the final write-up and the submission. Ideally, do not touch the paper for a day or two, and read it again before the submission. You may see that you don’t understand some parts of what you wrote – so you can guess the reviewer will have no clue neither! Then, it’s time to rewrite these sections.
Remember, your research may be very good, but you have to present it in the best possible light to stand out of the crowd. In events where acceptance rate is under 25%, a minor detail can make the difference. So yes, whether you like it or not, there’s some marketing involved in getting your paper accepted.