Ayushi Rastogi

Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis

Open source software projects are characterized as self organizing and dynamic in which volunteers around the world primarily driven by self-motivation (and not necessarily monetary compensation) contribute and collaborate to a software product. In contrast to close source or proprietary software, the organizational structure and task allocation in an open source project setting is unstructured. Software project managers perform risk, threat and vulnerability analysis to gain insights into the organizational structure for de-risking or risk mitigation. For example, it is important for a project manager to have an understanding of critical employees, core team, subject matter experts, sub-groups, leaders and communication bridges. Software repositories such as defect tracking systems, versioning systems and mailing lists contains a wealth of valuable information that can be mined for solving practically useful software engineering tasks. In this paper, we present a systematic approach to mine defect tracking system for risk, threat and vulnerability analysis in a software project. We derive a collaboration network from a defect tracking system and apply social network analysis techniques to investigate the derived network for the purpose of risk and vulnerability analysis. We perform empirical analysis on bug report data of Mozilla Firefox project and present the results of our analysis. We demonstrate how important information pertaining to risk and vulnerability can be uncovered using network analysis techniques from static record keeping software archive such as the bug tracking system.

What Community Contribution Pattern Says about Stability of Software Project

Free/Libre Open Source Software (FLOSS) community management is an important issue. Contributor churn (joining or leaving a project) causes failure of the majority of software projects. In this paper, we present a framework to characterize stability of the community in software maintenance projects by mining Issue Tracking System (ITS). We identify key stability indicators and propose metrics to measure them. We conduct time series analysis on metrics data to examine the stability of the community. We model community participation patterns and forecast future behavior to help plan and support informed decision making. We present a case study of four years data of Google Chromium Project and investigate the inferential ability of the framework.

Forking and the Sustainability of the Developer Community Participation -- An Empirical Investigation on Outcomes and Reasons

A majority of OSS projects fails due to their inability to garner significant and sustained developer community participation. The problem proliferates when competing projects emerge from the source code of an existing project, a phenomenon called forking of the original project, claiming existing and potential developer community participation. In this study, we empirically analyze the influence of forking on the sustainability of the developer community participation in the original project. Further, we try to explain the observed behavior in terms of the characteristics of the project observed at the time of forking. A large-scale study of 2,217 projects hosted on GitHub shows that 1 in every 5 original projects observes a decline in the sustainability of the developer community participation after forking. We find that the negative effect is more pronounced in projects ported to GitHub from other platforms (≈ 20%), compared to GitHub developed projects (≈ 9%). We also find that the observed behavior can be explained in terms of the characteristics of the competing projects at the time of forking. For instance, in medium sized projects an increase in the maturity of the original project by a year decreases the odds of decline in the sustainability of the developer participation by 23%.

On the Personality Traits of GitHub Contributors

Peoples personality has the potential to explain the behavior in different situations. This understanding of the behavior is required to understand the intricacies of the team, which can then be used to optimize work performance. As an initial step towards optimizing work performance, in this paper, we explore the inferential power of the personality traits in explaining the behavior of contributors in various contexts of software development in GitHub. Analyses of 243 actively discussed projects showed that the contributors with extreme (high or low) levels of contributions are more neurotic compared to the contributors with medium-level of contributions. Analyses of 423 active contributors showed that contributors evolve as more conscientious, more extrovert and less agreeable over the years of participation. The findings of this study match our ideas and are promising for further explorations.

Does Contributor Characteristics Influence Future Participation? A Case Study on Google Chromium Issue Tracking System

Understanding and measuring factors influencing future participation is relevant to organizations. This information is useful for planning and strategic decision-making. In this work, we measure contributor characteristics and compute attrition to investigate their relationship by mining Issue Tracking System. We conduct experiments on four year data extracted from Google Chromium Issue Tracking System. Experimental results show that the likelihood of future participation increases with increase in relevance of role in project and level of participation in previous time-interval.

Relationship between geographical location and evaluation of developer contributions in github

Background Open source software projects show gender bias suggesting that other demographic characteristics of developers, like geographical location, can negatively influence evaluation of contributions too. Aim This study contributes to this emerging body of knowledge in software development by presenting a quantitative analysis of the relationship between the geographical location of developers and evaluation of their contributions on GitHub. Method We present an analysis of 70,000+ pull requests selected from 17 most actively participating countries to model the relationship between the geographical location of developers and pull request acceptance decision. Results and Conclusion We observed structural differences in pull request acceptance rates across 17 countries. Countries with no apparent similarities such as Switzerland and Japan had one of the highest pull request acceptance rates while countries like China and Germany had one of the lowest pull request acceptance rates. Notably, higher acceptance rates were observed for all but one country when pull requests were evaluated by developers from the same country.

Ramp-up Journey of New Hires: Do strategic practices of software companies influence productivity?

Software companies regularly recruit skilled and talented employees to meet evolving business requirements. Although companies expect early contributions, new hires often take several weeks to reach the same productivity level as existing employees. We refer to this transition of new hires from novices to experts as ramp-up journey. There can be various factors such as lack of technical skills or lack of familiarity with the process that influence the ramp-up journey of new hires. The goal of our work is to identify those factors and study their influence on the ramp-up journey. We expect the results from this study to help identify the need of various types of assistance to new hires to ramp-up faster. As a first step towards our goal, this paper explores the impact of two strategic practices, namely distributed development and internship on the ramp-up journey of new hires. Our results show that new hires in proximity to the core development team and new hires with prior internship experience perform better than others in the beginning. In the overall ramp-up journey, the effect of the two factors attenuates, yet nevertheless better compared to their counterparts. Product teams can use this information to pay special attention to non-interns and use better tools for distributed, cooperative work to help new hires ramp-up faster.

Do biases related to geographical location influence work-related decisions in GitHub?

Visible demographic characteristics are seen as elements of bias in offline work environments. In this study, we investigate the influence of the geographical location on the evaluation of pull requests in GitHub – the most popular online collaborative code development environment. We use a mixed-methods approach and present analyses of 70,000+ pull requests and 2,500+ survey responses. Quantitative analysis of GitHub projects’ data suggests that the geographical location significantly explains the pull request acceptance decisions. These observations are in agreement with the perceptions of submitters based on their experiences with bias. Integrators feel that it is easy to work with contributors from the same geographical location and that they encourage contributors from the same geographical location. However, integrators do not feel that contributors from some countries are better at writing pull requests compared to others.

Ramp-Up Journey of New Hires: Tug of War of Aids and Impediments

Hiring top talent is essential for any software companys success. After joining the company, new hires often spend weeks or months before making any major contribution and attaining the same productivity level as existing employees. We use the term ramp-up journey to refer to this transition of new hires from novice to experts. There can be several factors, such as lack of experience or lack of familiarity with processes unique to the new company, which influence the ramp-up journey. To understand such aids and impediments in the ramp-up journey, we conducted a study by analyzing data extracted from version control systems of eight large and popular product groups in Microsoft with several thousand software developers. In particular, we studied two aspects of the ramp-up journey. First, we studied time taken to make the first check-in into the version control system, an important milestone in the ramp-up journey indicating the first contribution. Second, we analyzed the time taken to reach the same productivity level as existing employees in terms of check-ins. We further augmented our quantitative study with qualitative results derived by surveying 411 professional developers. Our study produced promising results, including factors such as having a mentor, prior knowledge of required skill sets, and proactively asking questions, that could help reduce the ramp-up journey of new hires.