This webpage lists a set of suggestions for writing papers that are likely to be appreciated by the reviewers. The motivation for this page is that many times good papers fail to be appreciated (and hence accepted) due to misunderstandings between reviewers and authors. We hope that this document will help improve the average quality of the submitted papers.
Some rules are mandatory (e.g., the page limits) and if the paper does not comply with these, it will be rejected without even being reviewed. Other points are suggestions for organizing and structuring the paper that make it easier for reviewers to appreciate the quality of the work that has been done.
This document is in the form of an FAQ. You can use it as a checklist and go through it while writing your paper and before submission. Remember that you can re-submit updated versions of your paper until the deadline. So, if you realize there is something wrong just after you clicked on the “submit” button, you can still update the submitted paper until the deadline expires.
Page Limits: Is there a page limit? Is there a specific format for submissions?
The paper must be in the same format as used in the final published proceedings, i.e. two columns, 10pt text. Word and Latex templates for formatting your paper can be found here. (Note: the conference uses US Letter (8.5″ x 11″) trim size). The main body of each submitted paper is limited to 11 pages of technical content with additional pages permitted for the bibliography only. Papers exceeding the page limit will result in automatic rejection.
Please help the reviewers by putting page numbers on the submitted version of the paper. In Latex, this can be achieved by adding the following: \thispagestyle{plain} \pagestyle{plain} after \maketitle. If your paper is accepted, then do not forget to remove the page numbers again in the camera-ready version.
What if there isn’t enough space?
The general idea is that the submitted version of a paper must contain the same material that will, in the case of acceptance, be refined following the reviewer’s comment and go into the final proceedings. If you want to provide supplemental materials (e.g., source code, videos, etc.), you may still do so but need to obey the double-blind submission requirements. Specifically, instead of directly providing a URL or technical report number, you should include a note that the supplemental materials in question are available from the track chair upon request.
In you choose to provide supplemental materials, you must provide all such materials that a submission refers to in blinded form and prior to the submission deadline. The paper submission form provides an additional upload field for this purpose.
Note that the additional material will only be read at the reviewers’ discretion. Remember that reviewers must evaluate your submitted paper and not the supplemental materials. If the reviewers think the paper contains insufficient material to be published, then the paper may be rejected, regardless of the contents of the supplemental materials.
Originality: How do I convince the reviewers that my work is actually new?
The paper should clearly state the research problem, together with information about the key contributions. A good example of this is to have a clear explanation of the problem in the introduction, together with a well-balanced positioning of why this problem has not been completely solved before. A poor example is to just describe an implementation without saying anything about why this implementation exists or which problem it actually tries to solve. Without this information, the reviewers are left guessing what the actual problem is, which may lead to significant misunderstandings.
You should aim to clearly explain the relationship between your work and the existing state-of-the-art in terms of related work. Make clear where you have built on existing results and the key differences between the proposed approach and those that have been published previously, including prior work of your own. Also consider adding a short paragraph in the conclusions where you briefly summarize the main innovative technical contributions of the paper as well as explain the advantages of your new approach with respect to the state-of-the-art, also give a balanced view of its disadvantages. This is generally well appreciated by reviewers, and preferable to leaving it to the reviewers to point out any shortcomings.
Please, remember that double submissions are unacceptable because they could compromise the requirement for originality of the paper, and effectively duplicate the review effort. Check that your paper has enough new material with respect to other papers you published or submitted to other conferences/journals. Including material from a 4 or 6 pages work-in-progress or workshop paper that has been published is acceptable, provided that it does not have a DOI, or at least 30% new content has been added. Nevertheless, you should include a citation to that preliminary publication and explain its relationship to the paper.
Presentation: How important is the writing quality?
The quality of the writing in the paper is very important. The main goal of a paper is to communicate the technical aspects of the work to other people. If the paper is not written in correct English, reviewers may not be able to understand the merits of the paper. Therefore, it is more likely that your paper will get a low score on the technical aspects as well as on the presentation. Take some time to review the presentation of your paper. Automated spelling and grammar checkers can help avoid many minor mistakes. As well as proof reading your paper a number of times yourself, it is recommended that you ask other good writers among your colleagues for their comments and opinions on it. The submitted paper must already be correct. After it has been reviewed is not the time to make corrections to the writing.
Make sure that any notation used is clearly defined and distinct (do not use symbols that can easily be confused with one another). Over the years, a de-facto standard notation has developed that is used in many real-time systems papers. Where possible try and stay with this common notation as it gives reviewers familiar with it far fewer new things to remember when they read your paper. The best place to define terminology and notation is together in a section called “system model, terminology and notation” or something similar. This gives reviewers a single place to refer back to where they can find any symbols they need to look up again. If you have a large amount of notation in your paper, consider providing a table of notation. Make sure you define all notation and acronyms before they are used.
Make sure that all of your figures, diagrams and graphs are legible when printed out in black and white. (This is the way most reviewers look at the papers and most likely the way they will appear in the printed proceedings). Avoid the temptation to make your figures the size of a postage stamp or thumb nail in order to fit your content into the page limits. Figures should normally fill the column width. Make sure the different lines on the graphs are clearly distinguishable by using markers that are obviously different and where necessary using different line types (e.g. dashed, dotted). Make sure the text on the graphs is legible and not too small.
Evaluation: Is it mandatory to have experimental evaluations in the paper?
No, RTSS accepts a wide range of papers including pure theory papers with formal proofs. Nevertheless, experimental evaluation is an important aspect of many papers. The evaluation may arise from the implementation of a real system, or via the use of data from case studies, benchmarks, or synthetic workloads intended to model a wide range of real systems.
The basic idea is that a reader of your paper should be able to reproduce your experiments and obtain the same results. Hence, it is necessary to describe the experimental setup, including details of case study or benchmark data (or where it can be obtained) and how synthetic data (if used) has been generated. If you are reporting statistical data, you should make sure to present measures pertaining to the quality of the results obtained, for example confidence intervals, or variance.
To aid in the reproducibility of results, consider also making your evaluation code available by uploading it onto your web page or institution’s repository and including a reference and URL to it in the submitted paper. Note this is not compulsory but is well appreciated by the community.
Authors are expected to compare their work with the existing state-to-the-art to show the size, scope and significance of the improvements they have made. Experimental evaluations should seek to cover as broad but realistic range of parameters and cases as possible, giving a balanced view of performance, where possible with respect to existing work. Authors should avoid selecting specific cases where there may be a bias in favor of their approach.
Acknowledgements
This FAQ has been a joint effort by the RTSS, RTAS and ECRTS communities, a living document started by Giuseppe Lipari for ECRTS 2006 (ecrts06.tudos.org/authors_faq.shtml) with contributions by many others since.