Kinds of topics publishable in SEIP

Full papers address industrially-relevant problems through systematic investigations.

Each paper should describe a problem of practical importance, explain how the problem was investigated and in what context, and present evidence for the paper’s conclusions. The submission should have technical and empirical soundness.

Other aspects that should be included if appropriate are: discussing why the resolution of the problem is innovative, (cost-) effective, or efficient; providing a concise explanation of the approach, techniques, and methodologies employed; and explaining the insights or best practices that emerged, tools developed, and/or software processes involved.

Report on SE support tools that have been deployed

Program repair research has made tremendous progress over the last few years, and software development bots are now being in- vented to help developers gain productivity. In this paper, we inves- tigate the concept ofa “program repair bot” and present Repairnator. The Repairnator bot is an autonomous agent that constantly monitors test failures, reproduces bugs, and runs program repair tools against each reproduced bug. If a patch is found, Repairnator bot reports it to the developers. At the time of writing, Repairnator uses three different program repair systems and has been operating since February 2017. In total, it has studied 11 523 test failures over 1 609 open-source software projects hosted on GitHub, and has generated patches for 15 different bugs. Over months, we hit a number of hard technical challenges and had to make various design and engineering decisions. This gives us a unique experience in this area. In this paper, we reflect upon Repairnator in order to share this knowledge with the automatic program repair community

...

To sum up, our contributions are: • a blueprint design of a program repair bot for continuous integration (CI) build failures; • a set of unique empirical facts about program repair and bug reproduction collected over 11 523 CI build failures across 1 609 software projects; • 7 actionable recommendations to help authors of future pro- gram repair bots.

...

Keywords:

Source: How to design a program repair bot?: Insights from the repairnator project

Sharing pitfalls and challenges

Over the past decade with the rise of the Mining Software Repositories (MSR) field, the modelling of defects for large and long-lived systems has become one of the most common applications of MSR. The findings and approaches of such studies have attracted the attention of many of our industrial collaborators (and other practitioners worldwide). At the core of many of these studies is the development and use of analytical models for defects.

In this paper, we discuss common pitfalls and challenges that we observed as practitioners attempt to develop such models or reason about the findings of such studies. The key goal of this paper is to document such pitfalls and challenges so practitioners can avoid them in future efforts. We also hope that other academics will be mindful of such pitfalls and challenges in their own work and industrial engagements.

Source: An experience report on defect modelling in practice: Pitfalls and challenges

Investigate the usage of tools and methods in practice

Context: Open Source is getting more and more collaborative with industry. At the same time, modeling is today playing a crucial role in development of, e.g., safety critical software.

Goal: However, there is a lack of research about the use of modeling in Open Source. Our goal is to shed some light into the motivation and benefits of the use of modeling and its use within project teams.

Method: In this study, we perform a survey among Open Source developers. We focus on projects that use the Unified Modeling Language (UML) as a representative for software modeling.

Results: We received 485 answers of contributors of 458 different Open Source projects. Conclusion: Collaboration seems to be the most important motivation for using UML. It benefits new contributors and contributors who do not create models. Teams use UML during communication and planning of joint implementation efforts.

...

Source: Practices and perceptions of UML use in open source projects