Number Of Commits Research Articles

Using Version Control Information to Visualize Developers' Knowledge

It is not always clear in case of a software project who has the right amount of knowledge concerning a certain module or file. Programmers frequently ask questions like "Who knows the most about this code?" or "Who can I ask for help when I work on this module?". In a large, long-term software product, knowledge is distributed in an uneven way among developers. Developer fluctuation during the product lifetime might cause some parts of the code to be known very well by a multitude of developers, while other parts might sink to the "gray zone", where developer competence is dangerously scarce. It is important for the project management to identify such critical points, to avoid the complete loss of competence. Version control repositories contain loads of useful information about the evolution of a software project. This paper presents a developer-centered visualization that is intended to show individual, team-bound and company-bound knowledge of large legacy projects. The competence information is computed from the extracted version control information from Git repositories. The calculated competence value is based on the number of commits per developer and their significance. Aggregated views for teams and companies are available based on various heuristics. The visualization is implemented as a new plugin in CodeCompass, a standalone, open-source code comprehension software. Project managers and individual developers may both profit from the tool, whether it concerns software evolution, human-resource management, architecture, knowledge catch-up, or blame.

Learning from Very Little Data: On the Value of Landscape Analysis for Predicting Software Project Health

When data is scarce, software analytics can make many mistakes. For example, consider learning predictors for open source project health (e.g., the number of closed pull requests in 12 months time). The training data for this task may be very small (e.g., 5 years of data, collected every month means just 60 rows of training data). The models generated from such tiny datasets can make many prediction errors. Those errors can be tamed by a landscape analysis that selects better learner control parameters. Our niSNEAK tool (a) clusters the data to find the general landscape of the hyperparameters, then (b) explores a few representatives from each part of that landscape. niSNEAK is both faster and more effective than prior state-of-the-art hyperparameter optimization algorithms (e.g., FLASH, HYPEROPT, OPTUNA). The configurations found by niSNEAK have far less error than other methods. For example, for project health indicators such as C = number of commits, I = number of closed issues, and R = number of closed pull requests, niSNEAK ’s 12-month prediction errors are {I=0%, R=33% C=47%}, whereas other methods have far larger errors of {I=61%,R=119% C=149%}. We conjecture that niSNEAK works so well since it finds the most informative regions of the hyperparameters, then jumps to those regions. Other methods (that do not reflect over the landscape) can waste time exploring less informative options. Based on the preceding, we recommend landscape analytics (e.g., niSNEAK ) especially when learning from very small datasets. This article only explores the application of niSNEAK to project health. That said, we see nothing in principle that prevents the application of this technique to a wider range of problems. To assist other researchers in repeating, improving, or even refuting our results, all our scripts and data are available on GitHub at https://github.com/zxcv123456qwe/niSneak.

Comprehensive assessment of open source software ecosystem health

Recent surveys expose that the use of Open Source Software (OSS) is increasingly becoming a need for organizations in their development projects. However, deciding a proper OSS to be adopted or to contribute to its development is a complex and error-prone task. Analyzing the OSS ecosystem (OSSECO) health may help providing information about: (1) the OSS itself (number of commits, days after the last release, etc.); and (2) their main actors (number of contributors, partners, etc.). There exist proposals that go further and provide aggregated high-level indicators (e.g. visibility as an aggregation of number of community events, number of partners, and other metrics). Nevertheless, there is a lack of useful OSSECO analysis tools to ease the decision making on which OSSECO has the health required by a potential OSS adopter or contributor. In this work, we provide OSS-CARE (OSSeCo heAlthy monitoR and analysEr), an OSS-independent, fully automatic, and real-time framework to assess OSSECO’s health. OSS-CARE supports defining the ecosystem health objectives of potential OSS adopters, OSS contributors, and even OSS managers to inspect their provided health. These objectives are defined based on a well-established model characterizing health metrics that can be potentially aggregated by using a Bayesian network technique. Moreover, the integrated monitoring and analysis components perform an automated assessment of OSSECO’s health by checking the fulfillment of the required health objectives. Furthermore, the result is shown in an appealing dashboard that may ease the complex decision making of which OSS to choose.

Pull request latency explained: an empirical overview

Pull request latency evaluation is an essential application of effort evaluation in the pull-based development scenario. It can help the reviewers sort the pull request queue, remind developers about the review processing time, speed up the review process and accelerate software development. There is a lack of work that systematically organizes the factors that affect pull request latency. Also, there is no related work discussing the differences and variations in characteristics in different scenarios and contexts. In this paper, we collected relevant factors through a literature review approach. Then we assessed their relative importance in five scenarios and six different contexts using the mixed-effects linear regression model. We find that the relative importance of factors differs in different scenarios, e.g., the first response time of the reviewer is most important when there exist comments. Meanwhile, the number of commits in a pull request has a more significant impact on pull request latency when closing than submitting due to changes in contributions brought about by the review process.

Attributes that may raise the occurrence of merge conflicts

Collaborative software development typically involves the use of branches. The changes made in different branches are usually merged, and direct and indirect conflicts may arise. Some studies are concerned with investigating ways to deal with merge conflicts and measuring the effort that this activity may require. However, the investigation of factors that may reduce the occurrence of conflicts needs more and deeper attention. This paper aims at identifying and analyzing attributes of past merges with and without conflicts to understand what may induce direct conflicts. We analyzed 182,273 merge scenarios from 80 projects written in eight different programming languages to find characteristics that increase the chances of a merge to have a conflict. We found that attributes such as the number of changed files, the number of commits, the number of changed lines, and the number of committers demonstrated to have the strongest influence in the occurrence of merge conflicts. Moreover, attributes in the branch that is being integrated seem to be more influential than the same attributes in the receiving branch. Additionally, we discovered positive correlations between the occurrence of conflicts and both the duration of the branch and the intersection of developers in both branches. Finally, we observed that PHP, JavaScript, and Java are more prone to conflicts.

Empirical Study of Test Case and Test Framework Presence in Public Projects on GitHub

Automated tests are often considered an indicator of project quality. In this paper, we performed a large analysis of 6.3 M public GitHub projects using Java as the primary programming language. We created an overview of tests occurrence in publicly available GitHub projects and the use of test frameworks in them. The results showed that 52% of the projects contain at least one test case. However, there is a large number of example tests that do not represent relevant production code testing. It was also found that there is only a poor correlation between the number of the word “test” in different parts of the project (e.g., file paths, file name, file content, etc.) and the number of test cases, creation date, date of the last commit, number of commits, or number of watchers. Testing framework analysis confirmed that JUnit is the most used testing framework with a 48% share. TestNG, considered the second most popular Java unit testing framework, occurred in only 3% of the projects.

Investigation and prediction of open source software evolution using automated parameter mining for agent-based simulation

To guide software development, the estimation of the impact of decision making on the development process can be helpful in planning. For this estimation, often prediction models are used which can be learned from project data. In this paper, an approach for the usage of agent-based simulation for the prediction of software evolution trends is presented. The specialty of the proposed approach lies in the automated parameter estimation for the instantiation of project-specific simulation models. We want to assess how well a baseline model using average (commit) behavior of the agents (i.e., the developers) performs compared to models where different amount of project-specific data is fed into the simulation model. The approach involves the interplay between the mining framework and simulation framework. Parameters to be estimated include, e.g., file change probabilities of developers and the team constellation reflecting different developer roles. The structural evolution of software projects is observed using change coupling graphs based on common file changes. For the validation of simulation results, we compare empirical with simulated results. Our results showed that an average simulation model can mimic general project growth trends like the number of commits and files well and thus, can help project managers in, e.g., controlling the onboarding of developers. Besides, the simulated co-change evolution could be improved significantly using project-specific data.

What factors influence the lifetime of pull requests?

SummaryWhen external contributors want to collaborate with an open‐source project, they fork the repository, make changes, and send a pull request to the core team. However, the lifetime of a pull request, defined by the time interval between its opening and its closing, has a high variation, potentially affecting the contributor engagement. In this context, understanding the root causes of pull request lifetime is important to both the external contributors and the core team. The former can adopt strategies that increase the chances of fast review, while the latter can establish priorities in the reviewing process, alleviating the pending tasks and improving the software quality. In this work, we mined association rules from 97,463 pull requests from 30 projects in order to find characteristics that have affected the pull requests lifetime. In addition, we present a qualitative analysis, helping to understand the patterns discovered from the association rules. The results indicate that: (i) contributions with shorter lifetimes tend to be accepted; (ii) structural characteristics, such as number of commits, changed files, and lines of code, have influence, in an isolated or combined way, on the pull request lifetime; (iii) the files changed and the directories to which they belong can be robust predictors for pull request lifetime; (iv) the profile of external contributors and their social relationships have influence on lifetime; and (v) the number of comments in a pull request, as well as the developer responsible for the review, are important predictors for its lifetime.

Learning to detect community smells in open source software projects

Community smells are symptoms of organizational and social issues within the software development community that often lead to additional project costs. Recent studies identified a variety of community smells and defined them as sub-optimal patterns connected to organizational-social structures in the software development community. To early detect and discover existence of potential community smells in a software project, we introduce, in this paper, a novel machine learning-based detection approach, named csDetector, that learns from various existing bad community development practices to provide automated support in detecting such community smells. In particular, our approach learns from a set of organizational-social symptoms that characterize the existence of potential instances of community smells in a software project. We built a detection model using Decision Tree by adopting the C4.5 classifier to identify eight commonly occurring community smells in software projects. To evaluate the performance of our approach, we conduct an empirical study on a benchmark of 74 open source projects from Github. Our statistical results show a high performance of csDetector, achieving an average accuracy of 96% and AUC of 0.94. Moreover, our results indicate that the csDetector outperforms two recent state-of-the-art techniques in terms of detection accuracy. Finally, we investigate the most influential community-related metrics to identify each community smell type. We found that the number of commits and developers per time zone, the number of developers per community, and the social network betweenness and closeness centrality are the most influential community characteristics.

Modeling the impact of Python and R packages using dependency and contributor networks

This paper develops methods to estimate the factors that affect the impact of open-source software (OSS), measured by number of downloads, with a study of Python and R packages. The OSS community is characterized by a high level of collaboration and sharing which results in interactions between contributors as well as packages due to reuses. We use data collected from Depsy.org about the development activities of Python and R packages, and generate the dependency and contributor networks. We develop three Quasi-Poisson models for each of the Python and R communities using network characteristics, as well as author and package attributes. We find that the more derivative a package is (the more dependencies it has), the less likely it is to have a high impact. We also show that the centrality of a package in the dependency network measured by the out-degree, closeness centrality, and pagerank has a significant effect on its impact. Moreover, the closeness and weighted degree centralities of the developers in the Python and R contributor networks play an important role. We also find that introducing network features to a baseline model using only package features (e.g., number of authors, number of commits) improves the performance of the models.

Analysis of human behavior statistics law based on WeChat Moment

WeChat is one of the most popular social platforms where users share their feelings and opinions in Moments, Wechat postings that are usually in forms of text, pictures and videos, etc. This paper analyze the Moment posting behavior of WeChat users by obtaining 10196 Moments of 628 users. According to the result, both the number of commits and the inter-event time conform to the power-law distribution in a continuous period of time, revealing a fact that the majority of Moments are posted by a small portion of users. Then our study on individual activity unveils a relatively strong positive correlation between user activity and the exponent of inter-event time distribution, which agrees with previous studies. Additionally, the paper points out that WeChat users have a low-burstiness, low-memory posting pattern, which is slightly different from that of other online systems owing to Wechat users’ generally high activity. This paper also studied the effects of sleep on user behavior. Our findings have significance in understanding the human dynamic mechanism of Wechat users.

Change profile analysis of open-source software systems to understand their evolutionary behavior

Source code management systems (such as git) record changes to code repositories of Open-Source Software (OSS) projects. The metadata about a change includes a change message to record the intention of the change. Classification of changes, based on change messages, into different change types has been explored in the past to understand the evolution of software systems from the perspective of change size and change density only. However, software evolution analysis based on change classification with a focus on change evolution patterns is still an open research problem. This study examines change messages of 106 OSS projects, as recorded in the git repository, to explore their evolutionary patterns with respect to the types of changes performed over time. An automated keyword-based classifier technique is applied to the change messages to categorize the changes into various types (corrective, adaptive, perfective, preventive, and enhancement). Cluster analysis helps to uncover distinct change patterns that each change type follows. We identify three categories of 106 projects for each change type: high activity, moderate activity, and low activity. Evolutionary behavior is different for projects of different categories. The projects with high and moderate activity receive maximum changes during 76–81 months of the project lifetime. The project attributes such as the number of committers, number of files changed, and total number of commits seem to contribute the most to the change activity of the projects. The statistical findings show that the change activity of a project is related to the number of contributors, amount of work done, and total commits of the projects irrespective of the change type. Further, we explored languages and domains of projects to correlate change types with domains and languages of the projects. The statistical analysis indicates that there is no significant and strong relation of change types with domains and languages of the 106 projects.

An empirical study on how project context impacts on code cloning

AbstractCode cloning can seriously affect software quality. Code clones are various fragments of syntactically or semantically equivalent code. Some authors argue that code clones have a negative impact on maintainability and understandability, since clones propagate defects and make it mandatory to pay attention to several copies. However, other authors believe clones are not necessarily bad, since self‐admitted clones favor system stability and allow developers to move projects forward. Although some root causes and effects of cloning have been widely studied, there is not much relevant work analyzing how certain projects context factors impact on code cloning. This work presents an empirical validation of six open source projects by considering certain factors from Git repositories measured throughout a total of 70 releases for the 6 systems. The factors analyzed were the number of commits and committers per release, the average size of the commits and the size of the system in each release. The main conclusion obtained from the study is that, while the number of commits and committers and the system size do not significantly affect cloning, larger commits lead to a higher cloning ratio. These insights contribute to predicting and preventing code cloning, thus enabling a software quality improvement.

What factors influence the reviewer assignment to pull requests?

ContextWhen external contributors want to collaborate with an open-source project, they can send a pull request to the project core team. Subsequently, a core team member is assigned to review the pull request. Recently, some techniques for recommending reviewers to analyze pull requests were proposed. However, they replicate previous (not always desired) patterns and do not provide the rationale behind the recommendation. ObjectiveThis paper aims at understanding the factors that influence on assigning reviewers to pull requests and evaluating the extent of this influence. MethodTo reach this goal, we mined association rules from 22,523 pull requests belonging to 3 projects hosted on GitHub. In addition to showing such patterns, we also present a qualitative analysis that explains why the patterns arose. ResultsIn summary our results indicate that (i) some reviewers always analyze smaller pull requests, with few commits and few files; (ii) some reviewers frequently (up to 58% of the times) analyze pull requests filed by inexperienced requesters; (iii) some reviewers have more chances (up to 25 times) to analyze pull requests filed by requesters of their acquaintance; and (iv) some reviewers have more chances (up to 20 times) to analyze pull requests containing files that they have recently changed. ConclusionIn particular, the results allow for the following conclusions: (i) factors such as number of commits and files in the pull request may influence the reviewers assignment; (ii) factors regarding the requester profile may influence on reviewer allocation; (iii) the social relationship between requester and reviewer exert influence on pull request evaluation, that is, when the reviewer knows the requester, his or her chances of evaluating such contributions may increase; and (iv) factors such as ownership and locality of pull request artifacts are important predictors for the reviewer. Furthermore, we point out that, besides identifying influence factors related to pull request reviewer, the adopted approach allowed us to quantify the extent of that influence via support, confidence, and lift metrics.

Multi-Perspective Exploratory Analysis of Software Development Data

In this paper, we present Dominoes, an approach for analyzing software repositories with thousands of artifacts by considering multiple perspectives of the software development data. In order to achieve computational power we model the data and its relationships as matrices, making possible to efficiently process them with a GPUs (Graphics Processing Unit) based architectures. Dominoes can support automated exploration of different relationships among project artifacts, where users have the flexibility to interactively combine and compose them. Our solution organizes data extracted from software repositories into multiple matrices that can be treated as domino pieces (e.g. [commit|method]). The connection of such pieces corresponds to a set of matrices operations, which derive additional domino pieces. These derived domino pieces represent specific project entity relationships (e.g. number of commits in which two methods co-occurred) and can be used for further explorations. As an evaluation of the Dominoes framework we present two exploratory case studies based on Apache Derby. First, we use Dominoes to show how dependencies among artifacts can be derived. Then, we identify expertise of developers by considering the commits that developers make to artifacts. We show that identifying relationships among 34,335 elements along 7,578 commits takes about 0.2 minutes in GPU, while the same processing in CPU takes about 413 minutes. Besides, identifying expertise of developer on a set of 34,335 files and 36 developers takes about 0.1 minute in GPU, whereas in CPU it takes 324 minutes.

Experiences tracking agile projects: an empirical study

In this article, we gather results from several projects we conducted recently that use some kind of agile method. We analyze both academic and governmental software development projects, some of them using agile methods since the beginning and others in which agile methods were introduced afterwards. Our main goals are to classify the different projects, and to analyze the collected data and discover which metrics are best suited to support tracking an agile project. We use both quantitative and qualitative methods, obtaining data from the source code, from the code repository, and from the feedback received from surveys and interviews held with the team members. We use various kinds of metrics such as lines of code, number of tests, cyclomatic complexity, number of commits, as well as combinations of these. In this article, we describe in detail the projects, the metrics, the obtained results, and their analysis from our main goals standpoint, providing guidelines for the use of metrics to track an agile software development project.

Experiences tracking agile projects: an empirical study

Abstract In this article, we gather results from several projects we conducted recently that use some kind of agile method. We analyze both academic and governmental software development projects, some of them using agile methods since the beginning and others in which agile methods were introduced afterwards. Our main goals are to classify the different projects, and to analyze the collected data and discover which metrics are best suited to support tracking an agile project. We use both quantitative and qualitative methods, obtaining data from the source code, from the code repository, and from the feedback received from surveys and interviews held with the team members. We use various kinds of metrics such as lines of code, number of tests, cyclomatic complexity, number of commits, as well as combinations of these. In this article, we describe in detail the projects, the metrics, the obtained results, and their analysis from our main goals standpoint, providing guidelines for the use of metrics to track an agile software development project.