RTSS 2022

Author FAQ

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 limit) 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 this page limit will be automatically rejected.

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 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 comments and go into the final proceedings. If you want to provide supplementary materials (e.g., source code, videos, etc.), you may still do so but you 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 supplementary materials in question are available from the Program Chair upon request.

If you choose to provide supplementary materials, you must provide all such materials that a submission refers to in blinded form and prior to the submission deadline. Such supplementary materials should either be submitted directly in the submission system (if the material is a PDF file) or should be emailed to the Program Chair (otherwise).

Note that the additional material will only be read at the reviewers’ discretion. Remember that reviewers must evaluate your submitted paper and not the supplementary 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 supplementary 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 conclusion section 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, while also giving a balanced view of its disadvantages. This is generally well appreciated by reviewers, and preferable over leaving it to the reviewers to point out any shortcomings.

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 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. In case of doubt, contact the Program Chair.

Remember that double submissions are unacceptable and will be considered as academic misconduct.

Presentation: How important is the writing quality?

The quality of 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. In addition to proofreading your paper a number of times yourself, it is recommended that you ask other good writers among your colleagues for their comments and opinion. The submitted paper must already be correct in terms of its language use.

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 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 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 thumbnail 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 camera-ready version once the paper is accepted (DO NOT include such URLs and references in the submitted paper so as to meet the double-blind submission requirements). Note this is not compulsory but is well appreciated by the community.

Authors are expected to compare their work with the existing state of 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.


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.