Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userWayback Machine: Capturing the evolutionary behaviour of the bug dependency graph in open-source software systems
52
0
0.0
(
0
)
Added by
Hadi Jahanshahi
Publication date
2020
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
The issue tracking system (ITS) is a rich data source for data-driven decision making. Different characteristics of bugs, such as severity, priority, and time to fix may be misleading. Similarly, these values may be subjective, e.g., severity and priority values are assigned based on the intuition of a user or a developer rather than a structured and well-defined procedure. Hence, we explore the dependency graph of the bugs and its complexity as an alternative to show the actual project evolution. In this work, we aim to overcome uncertainty in decision making by tracking the complexity of the bug dependency graph (BDG) to come up with a bug resolution policy that balances different considerations such as bug dependency, severity, and fixing time for the bug triaging. We model the evolution of BDG by mining issue tracking systems of three open-source projects for the past ten years. We first design a Wayback machine to examine the current bug fixing strategies, and then we define eight rule-based bug prioritization policies and compare their performances using ten distinct internal and external indices. We simulate the behavior of the ITS and trace back the effect of each policy across the history of the ITS. Considering the strategies related to the topology of the BDG, we are able to address bug prioritization problems under different scenarios. Our findings show that the network-related approaches are superior to the actual prioritization task in most cases. Among the selected open-source projects, LibreOffice triagers are the only ones who disregard the importance of the BDG, and that project is faced with a very dense BDG. Although we found that there is no single remedy that satisfies all the expectations of developers, the graph-related policies are found to be robust and deemed to be more suitable for bug triaging.
rate research
Read More
The development of scientific software is, more than ever, critical to the practice of science, and this is accompanied by a trend towards more open and collaborative efforts. Unfortunately, there has been little investigation into who is driving the evolution of such scientific software or how the collaboration happens. In this paper, we address this problem. We present an extensive analysis of seven open-source scientific software projects in order to develop an empirically-informed model of the development process. This analysis was complemented by a survey of 72 scientific software developers. In the majority of the projects, we found senior research staff (e.g. professors) to be responsible for half or more of commits (an average commit share of 72%) and heavily involved in architectural concerns (seniors were more likely to interact with files related to the build system, project meta-data, and developer documentation). Juniors (e.g.graduate students) also contribute substantially -- in one studied project, juniors made almost 100% of its commits. Still, graduate students had the longest contribution periods among juniors (with 1.72 years of commit activity compared to 0.98 years for postdocs and 4 months for undergraduates). Moreover, we also found that third-party contributors are scarce, contributing for just one day for the project. The results from this study aim to help scientists to better understand their own projects, communities, and the contributors behavior, while paving the road for future software engineering research
The bug triaging process, an essential process of assigning bug reports to the most appropriate developers, is related closely to the quality and costs of software development. As manual bug assignment is a labor-intensive task, especially for large-scale software projects, many machine-learning-based approaches have been proposed to automatically triage bug reports. Although developer collaboration networks (DCNs) are dynamic and evolving in the real-world, most automated bug triaging approaches focus on static tossing graphs at a single time slice. Also, none of the previous studies consider periodic interactions among developers. To address the problems mentioned above, in this article, we propose a novel spatial-temporal dynamic graph neural network (ST-DGNN) framework, including a joint random walk (JRWalk) mechanism and a graph recurrent convolutional neural network (GRCNN) model. In particular, JRWalk aims to sample local topological structures in a graph with two sampling strategies by considering both node importance and edge importance. GRCNN has three components with the same structure, i.e., hourly-periodic, daily-periodic, and weekly-periodic components, to learn the spatial-temporal features of dynamic DCNs. We evaluated our approachs effectiveness by comparing it with several state-of-the-art graph representation learning methods in two domain-specific tasks that belong to node classification. In the two tasks, experiments on two real-world, large-scale developer collaboration networks collected from the Eclipse and Mozilla projects indicate that the proposed approach outperforms all the baseline methods.
The HANDE quantum Monte Carlo project offers accessible stochastic algorithms for general use for scientists in the field of quantum chemistry. HANDE is an ambitious and general high-performance code developed by a geographically-dispersed team with a variety of backgrounds in computational science. In the course of preparing a public, open-source release, we have taken this opportunity to step back and look at what we have done and what we hope to do in the future. We pay particular attention to development processes, the approach taken to train students joining the project, and how a flat hierarchical structure aids communication
A novel modeling framework is proposed for dynamic scheduling of projects and workforce assignment in open source software development (OSSD). The goal is to help project managers in OSSD distribute workforce to multiple projects to achieve high efficiency in software development (e.g. high workforce utilization and short development time) while ensuring the quality of deliverables (e.g. code modularity and software security). The proposed framework consists of two models: 1) a system dynamic model coupled with a meta-heuristic to obtain an optimal schedule of software development projects considering their attributes (e.g. priority, effort, duration) and 2) an agent based model to represent the development community as a social network, where development managers form an optimal team for each project and balance the workload among multiple scheduled projects based on the optimal schedule obtained from the system dynamic model. To illustrate the proposed framework, a software enhancement request process in Kuali foundation is used as a case study. Survey data collected from the Kuali development managers, project managers and actual historical enhancement requests have been used to construct the proposed models. Extensive experiments are conducted to demonstrate the impact of varying parameters on the considered efficiency and quality.
[Context] Open Source Software (OSS) is nowadays used and integrated in most of the commercial products. However, the selection of OSS projects for integration is not a simple process, mainly due to a of lack of clear selection models and lack of information from the OSS portals. [Objective] We investigated the current factors and measures that practitioners are currently considering when selecting OSS, the source of information and portals that can be used to assess the factors, and the possibility to automatically get this information with APIs. [Method] We elicited the factors and the measures adopted to assess and compare OSS performing a survey among 23 experienced developers who often integrate OSS in the software they develop. Moreover, we investigated the APIs of the portals adopted to assess OSS extracting information for the most starred 100K projects in GitHub. [Result] We identified a set consisting of 8 main factors and 74 sub-factors, together with 170 related metrics that companies can use to select OSS to be integrated in their software projects. Unexpectedly, only a small part of the factors can be evaluated automatically, and out of 170 metrics, only 40 are available, of which only 22 returned information for all the 100K projects. [Conclusion.] OSS selection can be partially automated, by extracting the information needed for the selection from portal APIs. OSS producers can benefit from our results by checking if they are providing all the information commonly required by potential adopters. Developers can benefit from our results, using the list of factors we selected as a checklist during the selection of OSS, or using the APIs we developed to automatically extract the data from OSS projects.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
