Research PapersASE 2021

Call for Papers

The IEEE/ACM Automated Software Engineering (ASE) Conference series is the premier research forum for automated software engineering. Each year, it brings together researchers and practitioners from academia and industry to discuss foundations, techniques, and tools for automating the analysis, design, implementation, testing, and maintenance of large software systems. ASE 2021 invites high quality contributions describing significant, original, and unpublished results.

Solicited topics include, but are not limited to:

• Testing, verification, and validation
• Software analysis
• Empirical software engineering
• Maintenance and evolution
• Artificial intelligence for software engineering
• Software engineering for artificial intelligence
• Software security and trust; data privacy
• Recommender systems for software engineering
• Program synthesis & transformations, automated defect repair
• Program comprehension
• Mobile app development
• Automated reasoning techniques
• Software architecture and design
• Reverse engineering and re-engineering
• Model-driven development
• Knowledge acquisition and management
• Cloud computing
• Human-computer interaction
• Component-based service-oriented systems
• Specification languages
• Configuration management
• Requirements engineering
• Software product line engineering
• Software visualization

Two categories of submissions are solicited:

• Technical Research Papers should describe innovative research in automating software development activities or automated support to users engaged in such activities. They should describe a novel contribution to the field and should carefully support claims of novelty with citations to the relevant literature. Where a submission builds upon previous work of the author(s), the novelty of the new contribution must be clearly described with respect to the previous work, but the author identity should not be revealed, i.e., prior work should be referenced in the third person, to reflect the double-blind review policy. Papers should also clearly discuss how the results were validated

• Experience Papers should describe a significant experience in applying automated software engineering technology and should carefully identify and discuss important lessons learned, so that other researchers and/or practitioners can benefit from the experience. Of special interest are experience papers that report on industrial applications of automated software engineering.

Like ASE 2020, New Ideas Papers will be managed and evaluated by a separate track (Short Paper track), with a separate PC, deadline, etc.

SUBMISSION

Abstracts and papers must be submitted electronically through the ASE 2021 HotCRP submission site.

Format. All submissions must be in English.

All submissions must be in PDF format and conform, at time of submission, to the ACM Proceedings Template (LaTEX users must use \documentclass[sigconf,review,anonymous]{acmart}).

Papers submitted to this track (Technical Research and Experience Papers) must not exceed 10 pages (including figures) plus up to 2 pages that contain ONLY references. Exceeding this limit will be grounds for rejection without review.

Experience papers should contain the phrase “experience paper” prominently in the abstract, to ensure that they are evaluated appropriately.

The authors are strongly encouraged to use the HotCRP format checker on their submissions. Note that the format checker is not perfect. In particular, it can complain about small fonts in figures, footnotes, or references. As long as the main text follows the requested format, and the figures are readable, the paper will not be rejected for format violations. If you have any concerns, please contact the program chairs at ase2021research@gmail.com.

Originality. Papers submitted to ASE 2021 must not have been published elsewhere and must not be under review or submitted for review elsewhere when being considered for ASE 2021. Authors should be aware of the ACM Policy and Procedures on Plagiarism and the IEEE Plagiarism FAQ.

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, affiliated with ACM or IEEE, with overlapping review periods and (2) use external plagiarism detection software, under contract to the ACM or IEEE, to detect violations of these policies.

ASE 2021 will pursue a double-blind review process. If you have any questions, please see FAQs and/or contact the PC chairs at ase2021research@gmail.com. Authors are encouraged to double check conflicts of interest on their papers in HotCRP shortly after the submission deadline.

Submissions that do not adhere to these limits or that violate the formatting guidelines will be desk-rejected without review.

Supplementary material. Supplementary material can be uploaded via the HotCRP site or anonymously linked from the paper submission. Although PC members are not obligated to look at this material, we strongly encourage submitters to use supplementary material to provide access to anonymized code or data, whenever possible. Please carefully review any supplementary material to ensure it conforms to the double-blind policy (described next). For example, code and data repositories may be exported to remove version control history, scrubbed of names in comments and metadata, and anonymously uploaded to a sharing site to support review. One resource that may be helpful in accomplishing this task is this blog post:

https://ineed.coffee/5205/how-to-disclose-data-for-double-blind-review-and-make-it-archived-open-data-upon-acceptance/

ACCEPTED PAPERS

Accepted papers will be permitted an additional page of content to allow authors to incorporate review feedback. The page limit for published papers will therefore be 11 pages (including figures), plus 2 pages which may only contain references. Note that all submitted papers must conform to the 10+2 requirement, described above.

We strongly encourage authors of accepted papers to archive the research artifacts, including code and data, associated with their ASE papers. Software Heritage (presented in a keynote at ASE 2018) requires only providing a URL to an existing archive:

https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/

Other often used solutions, focusing on data, include Figshare and Zenodo.

If you have questions not answered below, please contact the program chairs at ase2021research@gmail.com

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. Over the past several years, this model has become an accepted practice at many Software Engineering conferences, and it is standard in many other communities as well. For more information on the motivation for double-blind reviewing, see Claire Le Goues’ blog post arguing 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.

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 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:

• Omit all authors’ names and affiliations from the title page. If you have acknowledgments, do not mention any names or organizations. Take care not to inadvertently include this information in PDF metadata.
• Refer to your own work in the third person. You should not omit or change the names of your own previously published tools, approaches, or systems, because 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.
• Take care with the use of supplementary material in the paper. Try to avoid relying on supplementary material that is impossible to properly anonymize, such as a companion technical report or thesis (see below), your personal website, or a YouTube channel. We do encourage the careful sharing of suitably anonymized code repositories and datasets, such as through an anonymous sharing links (doable via DropBox, for example) to a cleaned and anonymized GitHub repository. Check such data files and repositories carefully for any information that could reveal author identities. It is also possible to submit supplementary material with the paper, but again it is necessary to check the material carefully for anything that can reveal author identity.

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

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 should not discuss your work specifically 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 the submitted work on arXiv or a similar site immediately before or after submitting to the conference. One option is to make a tech report at your institution, which allows someone to cite the work, if need be, like arXiv, but doesn’t have the same degree of visibility.

Q: I published a previous version of my work on arXiv or as a tech report at my institution. Do I need to cite it, and if so how?

A paper on arXiv or a tech report is not a peer-reviewed publication. If the submission completely subsumes the previous version, then there is no need to cite the previous version at all. We explicitly discourage “anonymous” references (e.g., “[31] —Reference omitted for double-blind review—”: if the cited report is necessary for a reviewer to fully understand the submission, then the relevant material should either be included in the submission, cited in the third person, or provided as suitably anonymized supplementary material (such as an anonymized appendix) hosted anonymously. Note that reviewers are not obligated to review such previous material, however, and so you should strive to make your submissions as stand-alone as possible (regardless of the double-blind review process).

Q: I previously published an earlier version of this work elsewhere than arXiv. What should I do about citing that previous work? 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. This would include posters, but only if the poster is accompanied by a paper in the conference proceedings. Posters that are not represented in the proceedings can be ignored.

Q: What about a PhD or master’s thesis?

It’s perfectly fine to publish work arising from a PhD or master’s degree, and there’s no need to cite it in a submission that is undergoing double-blind review because prior dissertation publication does not compromise novelty. In the final camera-ready version of the paper, please do cite the dissertation to acknowledge its contribution. In general, the guideline is that the author’s job is to ensure that the 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’ identities. The referees will be trying hard not to discover the authors’ identities, so they will likely not be searching the web to check whether there is a tech report or other unpublished material related to this work.

This FAQ is based on guidelines for double-blind reviewing from ASE 2019 and ICSE 2019.