Software logging is the practice of recording different events that occur within a software system, which are useful for several analysis activities. However, striking the right balance between logging and system overhead is challenging. Prior work has conducted various machine learning-based solutions to suggest where to insert logging statements. But most importantly, before answering the question “where to log?’’, practitioners first need to determine whether a file needs logging at the first place. To do so, we conduct in this paper an empirical study to characterize the log density (i.e., ratio of log lines over the total lines of code) in seven open-source software projects. Then, we propose a deep learning based approach to predict the log density based on syntactic and semantic features of the source code. We find that the percentage of files with at least one log line ranges from 5% to 33% across the studied projects. Additionally, the median log density in the files with at least one log line ranges from 0.95% to 1.85% across the seven projects and can go up to 18%. Our findings resonate with the hypothesis that not all source code files require logging. On the other hand, our log density models achieve an average accuracy of 84%. Whereas our cross-project log density prediction results show a promising performance with an average accuracy of 72%, which represents over 86% (ratio of cross/within) of the corresponding within-project predictions using syntactic features. Our results show that we can accurately predict whether a file needs logging and such predictions may be generalized across projects.

The pull request mechanism is commonly used to propose source code modifications and get feedback from the community before merging them into a software repository. On GitHub, practitioners can provide feedback on a pull request by either commenting on the pull request or simply reacting to it using a set of pre-defined GitHub reactions, i.e., “Thumbs-up”, “Laugh”, “Hooray”, “Heart”, “Rocket”, “Thumbs-down”, “Confused”, and “Eyes”. While a large number of prior studies investigated how to improve different software engineering activities (e.g., code review and integration) by investigating the feedback on pull requests, they focused only on pull requests’ comments as a source of feedback. However, the GitHub reactions, according to our preliminary study, contain feedback that is not manifested within the comments of pull requests. In fact, our preliminary analysis of six popular projects shows that a median of 100% of the practitioners who reacted to a pull request did not leave any comment suggesting that reactions can be a unique source of feedback to further improve the code review and integration process. To help future studies better leverage reactions as a feedback mechanism, we conduct an empirical study to understand the usage of GitHub reactions and understand their promises and limitations. We investigate in this article how reactions are used, when and who use them on what types of pull requests, and for what purposes. Our study considers a quantitative analysis on a set of 380 k reactions on 63 k pull requests of six popular open-source projects on GitHub and three qualitative analyses on a total number of 989 reactions from the same six projects. We find that the most common used GitHub reactions are the positive ones (i.e., “Thumbs-up”, “Hooray”, “Heart”, “Rocket”, and “Laugh”). We observe that reactors use positive reactions to express positive attitude (e.g., approval, appreciation, and excitement) on the proposed changes in pull requests. A median of just 1.95% of the used reactions are negative ones, which are used by reactors who disagree with the proposed changes for six reasons, such as feature modifications that might have more downsides than upsides or the use of the wrong approach to address certain problems. Most (a median of 78.40%) reactions on a pull request come before the closing of the corresponding pull requests. Interestingly, we observe that non-contributors (i.e., outsiders who potentially are the “end-users” of the software) are also active on reacting to pull requests. On top of that, we observe that core contributors, peripheral contributors, casual contributors and outsiders have different behaviors when reacting to pull requests. For instance, most core contributors react in the early stages of a pull request, while peripheral contributors, casual contributors and outsiders react around the closing time or, in some cases, after a pull request is merged. Contributors tend to react to the pull request’s source code, while outsiders are more concerned about the impact of the pull request on the end-user experience. Our findings shed light on common patterns of GitHub reactions usage on pull requests and provide taxonomies about the intention of reactors, which can inspire future studies better leverage pull requests’ reactions.