38 research outputs found
How the Sando Search Tool Recommends Queries
Developers spend a significant amount of time searching their local codebase.
To help them search efficiently, researchers have proposed novel tools that
apply state-of-the-art information retrieval algorithms to retrieve relevant
code snippets from the local codebase. However, these tools still rely on the
developer to craft an effective query, which requires that the developer is
familiar with the terms contained in the related code snippets. Our empirical
data from a state-of-the-art local code search tool, called Sando, suggests
that developers are sometimes unacquainted with their local codebase. In order
to bridge the gap between developers and their ever-increasing local codebase,
in this paper we demonstrate the recommendation techniques integrated in Sando
Mining Sequences of Developer Interactions in Visual Studio for Usage Smells
In this paper, we present a semi-automatic approach for mining a large-scale dataset of IDE interactions to extract usage smells, i.e., inefficient IDE usage patterns exhibited by developers in the field. The approach outlined in this paper first mines frequent IDE usage patterns, filtered via a set of thresholds and by the authors, that are subsequently supported (or disputed) using a developer survey, in order to form usage smells. In contrast with conventional mining of IDE usage data, our approach identifies time-ordered sequences of developer actions that are exhibited by many developers in the field. This pattern mining workflow is resilient to the ample noise present in IDE datasets due to the mix of actions and events that these datasets typically contain. We identify usage patterns and smells that contribute to the understanding of the usability of Visual Studio for debugging, code search, and active file navigation, and, more broadly, to the understanding of developer behavior during these software development activities. Among our findings is the discovery that developers are reluctant to use conditional breakpoints when debugging, due to perceived IDE performance problems as well as due to the lack of error checking in specifying the conditional
Too Few Bug Reports? Exploring Data Augmentation for Improved Changeset-based Bug Localization
Modern Deep Learning (DL) architectures based on transformers (e.g., BERT,
RoBERTa) are exhibiting performance improvements across a number of natural
language tasks. While such DL models have shown tremendous potential for use in
software engineering applications, they are often hampered by insufficient
training data. Particularly constrained are applications that require
project-specific data, such as bug localization, which aims at recommending
code to fix a newly submitted bug report. Deep learning models for bug
localization require a substantial training set of fixed bug reports, which are
at a limited quantity even in popular and actively developed software projects.
In this paper, we examine the effect of using synthetic training data on
transformer-based DL models that perform a more complex variant of bug
localization, which has the goal of retrieving bug-inducing changesets for each
bug report. To generate high-quality synthetic data, we propose novel data
augmentation operators that act on different constituent components of bug
reports. We also describe a data balancing strategy that aims to create a
corpus of augmented bug reports that better reflects the entire source code
base, because existing bug reports used as training data usually reference a
small part of the code base
Uncovering the Causes of Emotions in Software Developer Communication Using Zero-shot LLMs
Understanding and identifying the causes behind developers' emotions (e.g.,
Frustration caused by `delays in merging pull requests') can be crucial towards
finding solutions to problems and fostering collaboration in open-source
communities. Effectively identifying such information in the high volume of
communications across the different project channels, such as chats, emails,
and issue comments, requires automated recognition of emotions and their
causes. To enable this automation, large-scale software engineering-specific
datasets that can be used to train accurate machine learning models are
required. However, such datasets are expensive to create with the variety and
informal nature of software projects' communication channels.
In this paper, we explore zero-shot LLMs that are pre-trained on massive
datasets but without being fine-tuned specifically for the task of detecting
emotion causes in software engineering: ChatGPT, GPT-4, and flan-alpaca. Our
evaluation indicates that these recently available models can identify emotion
categories when given detailed emotions, although they perform worse than the
top-rated models. For emotion cause identification, our results indicate that
zero-shot LLMs are effective at recognizing the correct emotion cause with a
BLEU-2 score of 0.598. To highlight the potential use of these techniques, we
conduct a case study of the causes of Frustration in the last year of
development of a popular open-source project, revealing several interesting
insights
Incivility in Open Source Projects: A Comprehensive Annotated Dataset of Locked GitHub Issue Threads
In the dynamic landscape of open source software (OSS) development,
understanding and addressing incivility within issue discussions is crucial for
fostering healthy and productive collaborations. This paper presents a curated
dataset of 404 locked GitHub issue discussion threads and 5961 individual
comments, collected from 213 OSS projects. We annotated the comments with
various categories of incivility using Tone Bearing Discussion Features
(TBDFs), and, for each issue thread, we annotated the triggers, targets, and
consequences of incivility. We observed that Bitter frustration, Impatience,
and Mocking are the most prevalent TBDFs exhibited in our dataset. The most
common triggers, targets, and consequences of incivility include Failed use of
tool/code or error messages, People, and Discontinued further discussion,
respectively. This dataset can serve as a valuable resource for analyzing
incivility in OSS and improving automated tools to detect and mitigate such
behavior
Recommended from our members
A Component Architecture for High-Performance Scientific Computing
The Common Component Architecture (CCA) provides a means for software developers to manage the complexity of large-scale scientific simulations and to move toward a plug-and-play environment for high-performance computing. In the scientific computing context, component models also promote collaboration using independently developed software, thereby allowing particular individuals or groups to focus on the aspects of greatest interest to them. The CCA supports parallel and distributed computing as well as local high-performance connections between components in a language-independent manner. The design places minimal requirements on components and thus facilitates the integration of existing code into the CCA environment. The CCA model imposes minimal overhead to minimize the impact on application performance. The focus on high performance distinguishes the CCA from most other component models. The CCA is being applied within an increasing range of disciplines, including combustion research, global climate simulation, and computational chemistry