Write a Blog >>

ICSE is the premier forum for presenting and discussing the most recent and significant technical research contributions in the field of Software Engineering. We invite high quality submissions of technical research papers describing original and unpublished results of software engineering research. We welcome submissions addressing topics across the full spectrum of Software Engineering.

Call for Papers

ICSE is the premier forum for presenting and discussing the most recent and significant technical research contributions in the field of Software Engineering. We invite high quality submissions of technical research papers describing original and unpublished results of software engineering research. We welcome submissions addressing topics across the full spectrum of Software Engineering including but not limited to:

            Agile software development                                                   Program analysis
            AI and software engineering                                                   Program comprehension
            Apps and app store analysis                                                  Program repair
            Autonomic and (self-)adaptive systems                                  Program synthesis
            Cloud computing                                                                    Programming languages
            Component-based software engineering                                Recommendation systems
            Configuration management and deployment                          Refactoring
            Crowd sourced software engineering                                      Requirements engineering
            Cyber physical systems                                                          Reverse engineering
            Debugging                                                                              Search-based software engineering
            Dependability, safety, and reliability                                        Security, privacy, and trust
            Distributed and collaborative software engineering                Software architecture
            Embedded software                                                                Software economics and metrics
            Empirical software engineering                                               Software evolution and maintenance
            End-user software engineering                                               Software modeling and design
            Fault localization                                                                     Software process
            Formal methods                                                                      Software product lines
            Green and sustainable technologies                                       Software reuse
            Human and social aspects of software engineering                Software services
            Human-computer interaction                                                   Software testing
            Middleware, frameworks, and APIs                                         Software visualization
            Mining software engineering repositories                                Specification and modeling languages
            Mobile applications                                                                  Tools and environments
            Model-driven engineering                                                        Traceability
            Parallel, distributed, and concurrent systems                          Validation and verification
            Performance

Review Criteria

Each paper submitted to the Technical Track will be evaluated based on the following criteria:

  • Soundness: The extent to which the paper’s contributions are supported by rigorous application of appropriate research methods

  • Significance: The extent to which the paper’s contributions are important with respect to open software engineering challenges

  • Novelty: The extent to which the contribution is sufficiently original and is clearly explained with respect to the state-of-the-art

  • Verifiability: The extent to which the paper includes sufficient information to support independent verification or replication of the paper’s claimed contributions

  • Presentation: The extent to which the paper’s quality of writing meets the high standards of ICSE, including clear descriptions and explanations, adequate use of the English language, absence of major ambiguity, clearly readable figures and tables, and adherence to the formatting instructions provided below

Reviewers will carefully consider all of these criteria during the review process, and as a result, high-quality papers may vary considerably in their type of contribution. For example, one paper could provide an extensive replication of prior work while another could describe a highly novel approach supported by non-trivial experimentation or empirical analysis.

How to Submit

  • All submissions must conform to the ICSE 2020 formatting and submission instructions and must not exceed 10 pages for the main text, inclusive of all figures, tables, appendices, etc. Two more pages containing only references are permitted. All submissions must be in PDF. The page limit is strict, and it will not be possible to purchase additional pages at any point in the process (including after the paper is accepted).

  • Formatting instructions are available at https://www.acm.org/publications/proceedings-template for both LaTeX and Word users. LaTeX users must use the provided acmart.cls and ACM-Reference-Format.bst without modification, enable the conference format in the preamble of the document (i.e., \documentclass[sigconf,review]{acmart}), and use the ACM reference format for the bibliography (i.e., \bibliographystyle{ACM-Reference-Format}). The review option adds line numbers, thereby allowing referees to refer to specific lines in their comments.

  • By submitting to the ICSE Research Track, authors acknowledge that they are aware of and agree to be bound by the ACM Policy and Procedures on Plagiarism (https://www.acm.org/publications/policies/plagiarism) and the IEEE Plagiarism FAQ (https://www.ieee.org/publications/rights/plagiarism/plagiarism-faq.html). In particular, papers submitted to ICSE 2020 must not have been published elsewhere and must not be under review or submitted for review elsewhere whilst under consideration for ICSE 2020. Contravention of this concurrent submission policy will be deemed a serious breach of scientific ethics, and appropriate action will be taken in all such cases. To check for double submission and plagiarism issues, the chairs reserve the right to (1) share the list of submissions with the PC Chairs of other conferences with overlapping review periods and (2) use external plagiarism detection software, under contract to the ACM or IEEE, to detect violations of these policies.

  • Lastly, the ICSE 2020 Technical Track will employ a double-blind review process. Thus, no submission may reveal its authors’ identities. The authors must make every effort to honor the double-blind review process. In particular, the authors’ names must be omitted from the submission and references to their prior work should be in the third person. Further advice, guidance, and explanation about the double-blind review process can be found in the Q&A page (https://conf.researchr.org/track/icse-2020/icse-2020-papers#Submitting-to-ICSE-Q-A).

Submissions to the Technical Track that meet the above requirements can be made via the Technical Track submission site (https://icse2020.hotcrp.com) by the submission deadline. We encourage the authors to upload their paper info early (and can submit the PDF later) to properly enter conflicts for double-blind reviewing.

Any submission that does not comply with these requirements may be desk rejected by the Technical Track PC Chairs without further review.

If a submission is accepted, at least one author of the paper is required to attend the conference and present the paper in person. In addition, the authors will be later invited to submit artifacts related to the paper to be evaluated by the Artifact Evaluation Committee.

Please note that the Double Blind Review (DBR) process is not used by all tracks. Check in the call for papers whether DBR is used or not.

Q: Why Double Blind?

There are many reasons for a submission track to employ a double-blind review process – not the least being the considerable number of requests to do so from the community. For more information on motivations for double-blind reviewing, see Claire Le Goues’s very well argued, referenced and evidenced blog posting in favor of double-blind review processes for Software Engineering conferences. See also a list of double-blind resources from Robert Feldt, as well as a more formal study of the subject by Moritz Beller​​ and Alberto Bacchelli​​ (see https://pure.tudelft.nl/portal/files/17721365/1589a385.pdf).

Q: How to prepare your paper for double-blind reviewing?

You must make every reasonable effort to honor the double-blind review process, but you do not need to guarantee that your identity is undiscoverable. The double-blind aspect of the review process is not to set up as an adversarial identity-discovery process. Essentially, the guiding principle should be to maximize the number of people who could plausibly be authors, subject to the constraint that no change is made to any technical details of the work. Therefore, you should ensure that the reviewers are able to read and review your paper without needing to know who any of the authors are. Specifically, this involves at least adhering to the following three points:

  1. Omit all authors’ names from the title page. Please note that it is not sufficient to simply change the font color to white, as names may appear when highlighted or on some printers; nor is it sufficient to cover the names with a rectangle. Also, please make sure that no identifying information is stored in the properties metadata of your submitted pdf. There are many ways to check this, for example from linux: $ pdfinfo paper.pdf or from Adobe Acrobat select File/Properties tab.

  2. Refer to your own work in the third person. You should not change the names of your own tools, approaches or systems, since this would clearly compromise the review process; it would also violate the constraint that “no change is made to any technical details of the work”. Instead, refer to the authorship or provenance of tools, approaches or systems in the third person, so that it is credible that another author could have written your paper. If for any reason it is completely impossible to reference your prior work in the third person, then you will need to provide a blinded reference and send a copy of the original paper to the chairs. However, in most cases we expect you to reference your own work in the third person.

  3. Do not rely on supplementary material (your web site, your github repository, a youTube channel, a companion technical report or thesis) in the paper or in the rebuttal submitted during the clarification period. We allow supplementary material to be uploaded in the submission system, but it is your responsibility to make sure it does not include identifying information. If you choose to upload supplementary material (either through the submission site or as a link), and your material includes identifying information, then your submission could be desk rejected. Furthermore, please keep in mind that reviewers are not obligated to read supplementary material.

Q: I previously published an earlier version of this work in a venue that doesn’t have double-blind. What should I do about acknowledging that previous work?

A: If the work you are submitting for review has previously been published in a non-peer-reviewed venue (e.g., arXiv.org, or a departmental tech report), there is no need to cite it, because work that has not been refereed is not truly part of the scientific literature.

If the previous work is published in a peer-reviewed venue, then it should be cited, but in the third person so that it is not revealed that the cited work and the submitted paper share one or more authors.

Q: Our submission makes use of work from a PhD or master’s thesis, dissertation, or report which has been published. Citing the dissertation might compromise anonymity. What should we do?

A: It’s perfectly OK to publish work arising from a PhD or master’s degree, and there’s no need to cite it in an ICSE submission that is undergoing double-blind review because prior dissertation publication does not compromise novelty. In the final post-review, camera ready version of the paper, please do cite the dissertation to acknowledge its contribution, but in any submission to an ICSE track employing a double-blind review process, please refrain from citing the dissertation, to increase anonymity.

You need not worry whether or not the dissertation has appeared. Your job is to ensure that your submission is readable and reviewable, without the reviewers needing to know the identities of the submission’s authors. You do not need to make it impossible for the reviewers to discover the authors’ identifies. The referees will be trying hard not to discover the authors’ identity, so they will likely not be searching the web to check whether there is a dissertation related to this work.

Q: What if we want to cite some unpublished work of our own (as motivation for example)

A: If the unpublished paper is an earlier version of the paper you want to submit to ICSE and is currently under review, then you have to wait until your earlier version is through its review process before you can build on it with further submissions (this would be considered double-submission and violates ACM plagiarism policy and procedures). Otherwise, if the unpublished work is not an earlier version of the proposed ICSE submission, then you should simply make it available on a website, for example, and cite it in the third person to preserve anonymity, as you are doing with others of your works.

Q: Can I disseminate non-blinded version of my submitted work by discussing it with colleagues, giving talks, publishing it at ArXiV, etc.?

A: You can discuss and present your work that is under submission at small meetings (e.g., job talks, visits to research labs, a Dagstuhl or Shonan meeting), but you should avoid broadly advertising it in a way that reaches the reviewers even if they are not searching for it. For example, you are allowed to put your submission on your home page and present your work at small professional meetings. However, you should not discuss your work with members of the program committee, publicize your work on mailing lists or media that are widely shared and can reach the program committee, or post your work on ArXiV or a similar site just before or after submitting to the conference.