Software development, like any prolonged and intellectually demanding activity, can negatively affect the motivation of developers. This is especially true in specific areas of software engineering, such as requirements engineering, test-driven development, bug reporting and fixing, where the creative aspects of programming fall short. The developers' engagement might progressively degrade, potentially impacting their work's quality.

To ensure quality of software systems, developers use bug reports to track defects. It is in the interest of users and developers that bug reports provide the necessary information to ease the fixing process. Past research found that users do not provide the information that developers deem ideally useful to fix a bug. This raises an interesting question: What is the satisficing information to speed up the bug fixing process? We conducted an observational study on the relation between provided report information and its lifetime, considering more than 650,000 reports from open-source systems using popular bug trackers. We distilled a meta-model for a minimal bug report, establishing a basic layer of core features. We found that few fields influence the resolution time and that customized fields have little impact on it. We performed a survey to investigate what users deem easy to provide in a bug report.

While constructing and evolving software systems, developers generate directly and indirectly a large amount of data of diverse nature, such as source code changes, bug tracking information, IDE interactions, stack traces, etc. Often these diverse data sources are processed and visualized in isolation, leading to a partial view of systems. We present a blended approach to visualize several data “ingredients” at once, to give as complete an answer as possible to the question “What happened to the system in the last few days?”. The goal is to enable a quick and comprehensive assessment of what happened to a software system in any given time frame.

During software development, exceptions are by no means exceptional: Programmers repeatedly try and test their code to ensure that it works as expected. While doing so, runtime exceptions are raised, pointing out various issues, such as inappropriate usage of an API, convoluted code, as well as defects. Such failures result in stack traces, lists composed of the sequence of method invocations that led to the interruption of the program. Stack traces are useful to debug source code, and if shared also enhance the quality of bug reports. However, they are handled manually and individually, while we argue that they can be leveraged automatically and collectively to enable what we call crowdstacking, the automated collection of stack traces on the scale of a whole development community. We present our crowdstacking approach, supported by Shore-Line Reporter, a tool which seamlessly collects stack traces during program development and execution and stores them on a central repository. We illustrate how thousands of stack traces stemming from the IDEs of several developers can be leveraged to identify common hot spots in the code that are involved in failures, using this knowledge to retrieve relevant and related bug reports and to provide an effective, instant context of the problem to the developer.

Our work aims to improve the workflow of developers dealing with bug reports. This begins with promoting a bug report-often considered as a side effect of the development process-to independent entity with specific properties that can be exploited to describe and understand a system. We believe that, by automating the steps that lead to the creation of a bug report, we can generate meaningful information that can be automatically elaborated to produce insightful views on the failure environment and aid the interpretation of a bug report. Finally, we want to integrate the reporting process with elements from game design theory, to stimulate interaction between developers and people in the community and create fruitful cooperation in software ecosystems.

The evolution of non-trivial software systems is accompanied by unexpected behaviour and side-effects, referred as bugs or defects. These defects are reported to and stored in bug tracking systems, which contain descriptions of the problems that have been encountered. However, bug tracking systems store and present bug reports in textual form, which makes their understanding dispersive and unintuitive. We present an approach to display bug reports through a web-based visual analytics platform, named in∗Bug. in∗Bug allows users to navigate and inspect the vast information space created by bug tracking systems, with the goal of easing the comprehension of bug reports in detail and also obtain an understanding “in the large” of how bugs are reported with respect to one system or to an entire software ecosystem.

Emails related to the development of a software system contain information about design choices and issues encountered during the development process. Exploiting the knowledge embedded in emails with automatic tools is challenging, due to the unstructured, noisy, and mixed language nature of this communication medium. Natural language text is often not well-formed and is interleaved with languages with other syntaxes, such as code or stack traces. We present an approach to classify email content at line level. Our technique classifies email lines in five categories (i.e., text, junk, code, patch, and stack trace) to allow one to subsequently apply ad hoc analysis techniques for each category. We evaluated our approach on a statistically significant set of emails gathered from mailing lists of four unrelated open source systems.