Abstract A recent survey using industrial projects has shown that providing an estimate of the lifetime of pull requests to developers helps to speed up their conclusion. Previous work has explored pull request lifetime prediction in open‐source projects using regression techniques but with a broad margin of error. The first objective of our work was to reduce the average error rate of the prediction obtained by the regression techniques so far. We performed experiments with different regression techniques and achieved a significant decrease in the mean error rate. The second objective of our work was to obtain a more effective and useful predictive model that can classify pull requests according to five discrete time intervals. We proposed new predictive attributes for the estimation of the time intervals and employed attribute selection strategies to identify subsets of attributes that could improve the predictive behavior of the classifiers. Our classification approach achieved the best accuracy in all the 20 projects evaluated in comparison with the literature. The average accuracy was of 45.28% to predict pull request lifetime, with an average normalized improvement of 14.68% in relation to the majority class and 6.49% in relation to the state‐of‐the‐art.

Summary When 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.

When developers want to contribute to an opensource project, they fork the repository, make changes, and send a pull request to the core team to incorporate these changes back into the repository. However, some projects enforce this collaboration model even for changes made by core team developers. This potentially enhances the quality of the repository by adding an inspection step before accepting a contribution into the repository. In this context, though less frequently, the contributions may be rejected. The understanding of the factors that lead to the rejection of these internal contributions is crucial for the improvement of the ways core developers collaborate, having a direct impact on the team productivity. In this work we extract association rules from pull request data stored in software repositories in order to find factors that have influence over the decision of rejecting contributions made by core developers. In addition, we present a qualitative analysis of some cases, helping to understand the patterns that arose from the association rules. The results indicate that some key factors increase the changes of having internal contributions rejected: (i) the inexperience with pull requests, (ii) the complexity of contributions, as well as the locality of the artifacts that have been modified, and (iii) the contribution policy of the projects.