Code review is a broadly adopted software quality practice where developers critique each others’ patches. In addition to providing constructive feedback, reviewers may provide a score to indicate whether the patch should be integrated. Since reviewer opinions may differ, patches can receive both positive and negative scores. If reviews with divergent scores are not carefully resolved, they may contribute to a tense reviewing culture and may slow down integration. In this article, we study patches with divergent review scores in theOpenStackandQtcommunities. Quantitative analysis indicates that patches with divergent review scores: (1) account for 15–37 percent of patches that receive multiple review scores; (2) are integrated more often than they are abandoned; and (3) receive negative scores after positive ones in 70 percent of cases. Furthermore, a qualitative analysis indicates that patches with strongly divergent scores that: (4) are abandoned more often suffer from external issues (e.g., integration planning, content duplication) than patches with weakly divergent scores and patches without divergent scores; and (5) are integrated often address reviewer concerns indirectly (i.e., without changing patches). Our results suggest that review tooling should integrate with release schedules and detect concurrent development of similar patches to optimize review discussions with divergent scores. Moreover, patch authors should note that even the most divisive patches are often integrated through discussion, integration timing, and careful revision.

A benchmark is an action to assess performance (e.g., program execution time) by developers preparing and running several test cases over a long period. To reasonably assess the performance of method-level code snippets, developers could use a micro benchmark. Some micro benchmarks for JavaScript provide online web services (e.g., jsPerf and MeasureThat.net). Developers easily search code snippets with better performance in the micro benchmark service. Then, the developers will find many similar code snippets for different functions in the service because the micro benchmark service has a collection of versatile method-level code snippets. To find replaceable code snippets with better performance, we tackle to distinguish similar code snippets for different functions with more fine-grained size than method-level in micro benchmark services.This study proposes an approach to collect diverse code snippets using the similar function. The approach measures the similarity using Code2Vec between some code snippets assessed in the micro benchmark service, and find an appropriate threshold to associate with the code snippets using the similar function. Using the micro benchmark service jsPerf dataset that the authors collected, this study evaluates the usefulness of our approach. Specifically, we collect code snippets related to the most frequent topics "innerHTML vs removeChild" and "for vs forEach" assessed in jsPerf. Consequently, we find our approach achieves higher precision (98% and 92%) to identify diverse code snippets using the similar function.

Open Source Software (OSS) developers are free to contribute and free to leave a project, if the project is (not) suitable for them. On the one hand, OSS projects need to manage the human resource to continuously maintain OSS in the future. Some existing studies proposed an approach that estimates how long developers contribute to OSS projects. Using developers’ contributions during the first few months in the target project, the proposed model identified long-term contributors or core developers. However, the approach frequently miss to find capable developers because many developers leave the project soon after participating. To avoid the loss of capable developers, this study build a prediction model to identify future active developers based on their past contributions to any OSS projects. Using dataset from four large-scale OSS projects as a case study, we evaluated our proposed model to identify future active developers based on their past contributions to any OSS projects before participating in a future target project. Our proposed approach contributes to manage human resource in OSS development process.

Abstract Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem.

Modern Code Review (MCR) is a pillar of contemporary quality assurance approaches, where developers discuss and improve code changes prior to integration. Since review interactions (e.g., comments, revisions) are archived, analytics approaches like reviewer recommendation and review outcome prediction have been proposed to support the MCR process. These approaches assume that reviews evolve and are adjudicated independently; yet in practice, reviews can be interdependent.

Abstract Bug reports are the primary means through which developers triage and fix bugs. To achieve this effectively, bug reports need to clearly describe those features that are important for the developers. However, previous studies have found that reporters do not always provide such features. Therefore, we first perform an exploratory study to identify the key features that reporters frequently miss in their initial bug report submissions. Then, we propose an approach that predicts whether reporters should provide certain key features to ensure a good bug report. A case study of the bug reports for Camel, Derby, Wicket, Firefox, and Thunderbird projects shows that Steps to Reproduce, Test Case, Code Example, Stack Trace, and Expected Behavior are the additional features that reporters most often omit from their initial bug report submissions. We also find that these features significantly affect the bug‐fixing process. On the basis of our findings, we build and evaluate classification models using four different text‐classification techniques to predict key features by leveraging historical bug‐fixing knowledge. The evaluation results show that our models can effectively predict the key features. Our comparative study of different text‐classification techniques shows that naïve Bayes multinomial (NBM) outperforms other techniques. Our findings can benefit reporters to improve the contents of bug reports.

Background: Code review is a well-established software quality practice where developers critique each others' changes. A shift towards automated detection of low-level issues (e.g., integration with linters) has, in theory, freed reviewers up to focus on higher level issues, such as software design. Yet in practice, little is known about the extent to which design is discussed during code review.

It has become common practice for software projects to adopt third-party libraries, allowing developers full access to functions that otherwise will take time and effort to create them-selves. Regardless of migration effort involved, developers are encouraged to maintain their library dependencies by updating any outdated dependency, so as to remain safe from potential threats such as vulnerabilities. Through a manual inspection of a total of 60 client projects from three cases of high severity vulnerabilities, we investigate whether or not clients are really safe from these threats. Surprisingly, our early results show evidence that up to 73.3% of outdated clients were actually safe from the threat. This is the first work to confirm that analysis at the library level is indeed an overestimation. This result to pave the path for future studies to empirically investigate and validate this phenomena, and is towards aiding a smoother library migration for client developers.

A key goal of this research is to understand the relationship between adoption of software library versions and its release cycle. In detail, we conducted an empirical study of the release cycle of 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our preliminary findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle.

Open Source Software (OSS) cannot exist without contributions from the community. In particular, long-term contributors (LTCs) (e.g., committer), defined as contributors who spend at least one year on OSS projects, play crucial role in a project success because they would have permission to add (commit) code changes to a project's version control system, and to become a mentor for a beginner in OSS projects. However, contributors often leave a project before becoming a LTC because most contributors are volunteers. If contributors are motivated in their work in OSS projects, they might not leave the projects. In this study, we examine the phenomena involved in becoming a LTC in terms of motivation to continue in OSS projects. In particular, our target motivation is to understand what is involved in long-term contribution with other expert contributors. We study classifier to identify a LTC who will contribute patch submissions for more than one year based on collaboration in terms of the code review process. In detail, we analyze what review feedbacks encourage a contributor to continue with OSS project. Using a Qt project dataset, we understand review feedback which affected contribution period of the developer.

The reliability of a prediction model depends on the quality of the data from which it was trained. Therefore, defect prediction models may be unreliable if they are trained using noisy data. Recent research suggests that randomly-injected noise that changes the classification (label) of software modules from defective to clean (and vice versa) can impact the performance of defect models. Yet, in reality, incorrectly labelled (i.e., mislabelled) issue reports are likely non-random. In this paper, we study whether mislabelling is random, and the impact that realistic mislabelling has on the performance and interpretation of defect models. Through a case study of 3,931 manually-curated issue reports from the Apache Jackrabbit and Lucene systems, we find that: (1) issue report mislabelling is not random; (2) precision is rarely impacted by mislabelled issue reports, suggesting that practitioners can rely on the accuracy of modules labelled as defective by models that are trained using noisy data; (3) however, models trained on noisy data typically achieve 56%-68% of the recall of models trained on clean data; and (4) only the metrics in top influence rank of our defect models are robust to the noise introduced by mislabelling, suggesting that the less influential metrics of models that are trained on noisy data should not be interpreted or used to make decisions.

The importance of supporting test and maintenance activities in software development has been increasing, since recent software systems have become large and complex. Although in the field of Mining Software Repositories (MSR) there are many promising approaches to predicting, localizing, and triaging bugs, most of them do not consider impacts of each bug on users and developers but rather treat all bugs with equal weighting, excepting a few studies on high impact bugs including security, performance, blocking, and so forth. To make MSR techniques more actionable and effective in practice, we need deeper understandings of high impact bugs. In this paper we introduced our dataset of high impact bugs which was created by manually reviewing four thousand issue reports in four open source projects (Ambari, Camel, Derby and Wicket).

In an Open Source Software (OSS) project, many developers contribute by submitting source code patches. To maintain the quality of the code, certain experienced developers review each patch before it can be applied or committed. Ideally, within a short amount of time after its submission, a patch is assigned to a reviewer and reviewed. In the real world, however, many large and active OSS projects evolve at a rapid pace and the core developers can get swamped with a large number of patches to review. Furthermore, since these core members may not always be available or may choose to leave the project, it can be challenging, at times, to find a good reviewer for a patch. In this paper, we propose a graph-based method to automatically recommend the most suitable reviewers for a patch. To evaluate our method, we conducted experiments to predict the developers who will apply new changes to the source code in the Eclipse project. Our method achieved an average recall of 0.84 for top-5 predictions and a recall of 0.94 for top-10 predictions.

A large open source software (OSS) project receives many bug reports on a daily basis. Bug localization techniques automatically pinpoint source code fragments that are relevant to a bug report, thus enabling faster correction. Even though many bug localization methods have been introduced, their performance is still not efficient. In this research, we improved on existing bug localization methods by taking into account co-change histories. We conducted experiments on two OSS datasets, the Eclipse SWT 3.1 project and the Android ZXing project. We validated our approach by evaluating effectiveness compared to the state-of-the-art approach Bug Locator. In the Eclipse SWT 3.1 project, our approach reliably identified source code that should be fixed for a bug in 72.46% of the total bugs, while Bug Locator identified only 51.02%. In the Android ZXing project, our approach identified 85.71%, while Bug Locator identified 60%.

There are many roles to play in the bug fixing process in open source software development. A developer called ``Committer'', who has a permission to submit a patch into software repository, plays a major role in this process and hold a key to the successfulness of the project. In this work, we have observed each committer activities from the Eclipse-Platform bug tracking system and version archives. Despite the importance of committer's activities, we suspected that sometimes committers can make mistakes, which have negative consequences to the bug fixing process. Our research focus on studying the consequences of each committer's activities to this process. We collected each committer's historical data and evaluated each of them by comparing the more cautiousness to less cautiousness committers. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. From our results, we would like to make a humbly suggestion to the OSS's committers to be aware of their importance to the projects and be cautious before doing their jobs.

Patch submission has been known as one of the most important activities to sustain the open source software (OSS). The patch archive can be analyzed to procure many benefit cognizance for supporting the OSS project works. The recent models and methods that analyze the patches acceptance are quite rack of comprehensive; hence, complex activities such as a committer portioning the Passed QA patch out and accept are still excluded from the analysis. Therefore, the results derived from those methods would be inadequate to conclude the actual patch acceptance. In this research, we introduce an algorithm for analyzing patch acceptance including the partial and gradually accepted conditions. Validating our algorithm, we present our methods for indicating the partial and gradual application of the Passed QA patch between either mailing list and SVN or Bugzilla and CVS which are the commonly deployed patch-activities related system. We studied on two well known OSS projects; Apache HTTP and Eclipse Platform. We obtained a fascinating conclusion that larger patches have more confident to be accepted than the smaller contradicted to other analysis that came from the recent methods.