Peer code reviews play a critical role in maintaining code quality, and GitHub has introduced several new features to assist with the review process. One of these features is suggested changes, which allows for precise code modifications in pull requests to be suggested in review comments. Despite the availability of such helpful features, many pull requests remain unattended due to lower priority. To address this issue, we developed a bot called ``Suggestion Bot" to automatically review the codebase using GitHub's suggested changes functionality. An empirical study was also conducted to compare the effectiveness of this bot with manual reviews. The findings suggest that implementing this bot can expedite response times and improve the quality of pull request comments for pull-based software development projects. In addition to providing automated suggestions, this feature also offers valuable, concise, and targeted feedback. / Master of Science / Code review, often known as peer review, is a process used to ensure the quality of software. Code review is a process in software development that involves one or more individuals examining the source code of a program, either after it has been implemented or during a pause in the development process. The creator of the code cannot be one of the individuals. "Reviewers" refers to the individuals conducting the checking, excluding the author. However, the majority of reviewers won't have the time to examine and validate the peer's code base, so they'll assign it the lowest priority possible. This could cause pull requests to stall out without being reviewed. Therefore, as part of our research, we are creating a bot called SUGGESTION BOT that provides code changes in pull requests. The author can then accept, reject, or alter these ideas as a necessary component of the pull request. Additionally, we compared the effectiveness of our bot with the manual pull request review procedure, which clearly demonstrated that the incorporation of this bot significantly shortened the turnaround time. Besides giving automated recommendations, this functionality also provides useful, brief, and focused feedback.

No description available.

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2017-11-01T21:17:50Z No. of bitstreams: 1 JoaoHelisJuniorDeAzevedoBernardo_DISSERT.pdf: 3484130 bytes, checksum: f8c6117ef3a3facccdfb4317e8e41c61 (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2017-11-07T22:16:31Z (GMT) No. of bitstreams: 1 JoaoHelisJuniorDeAzevedoBernardo_DISSERT.pdf: 3484130 bytes, checksum: f8c6117ef3a3facccdfb4317e8e41c61 (MD5) / Made available in DSpace on 2017-11-07T22:16:31Z (GMT). No. of bitstreams: 1 JoaoHelisJuniorDeAzevedoBernardo_DISSERT.pdf: 3484130 bytes, checksum: f8c6117ef3a3facccdfb4317e8e41c61 (MD5) Previous issue date: 2017-07-31 / Conselho Nacional de Desenvolvimento Cient?fico e Tecnol?gico (CNPq) / A Integra??o Cont?nua (IC) ? uma pr?tica de desenvolvimento de software que leva os desenvolvedores a integrarem seu c?digo-fonte mais frequentemente. Projetos de software t?m adotado amplamente a IC com o intuito de melhorar a integra??o de c?digo e lan?ar novas releases mais rapidamente para os seus usu?rios. A ado??o da IC ? usualmente motivada pela atra??o de entregar novas funcionalidades do software de forma mais r?pida e frequente. Todavia, h? poucas evid?ncias emp?ricas para justificar tais alega??es. Ao longo dos ?ltimos anos, muitos projetos de software dispon?veis em ambientes de codifica??o social, como o GitHub, tem adotado a pr?tica da IC usando servi?os que podem ser facilmente integrados nesses ambientes (por exemplo, Travis-CI). Esta disserta??o investiga empiricamente o impacto da ado??o da IC no tempo de entrega de pull requests (PRs), atrav?s da an?lise de 167.037 PRs de 90 projetos do GitHub que s?o implementados em 5 linguagens de programa??o diferentes. Ao analisar a porcentagem de merged PRs por projeto que perderam pelo menos uma release antes de serem entregues aos usu?rios finais, os resultados mostraram que antes da ado??o da IC, em mediana 13.8% dos merged PRs tem sua entrega adiada por pelo menos um release, enquanto que ap?s a ado??o da IC, em mediana 24% dos merged PRs tem sua entrega adiada para futuras releases. Ao contr?rio do que se pode especular, observou-se que PRs tendem a esperar mais tempo para serem entregues ap?s a ado??o da IC na maioria (53%) dos projetos investigados. O grande aumento das submiss?es de PRs ap?s a IC ? uma raz?o fundamental para que projetos demorem mais tempo para entregar PRs depois da ado??o da IC. 77,8% dos projetos aumentam a taxa de submiss?es de PRs ap?s a ado??o da IC. Com o prop?sito de investigar os fatores relacionados ao tempo de entrega de merged PRs, treinou-se modelos de regress?o linear e log?stica, os quais obtiveram R-Quadrado mediano de 0.72-0.74 e bons valores medianos de AUC de 0.85-0.90. An?lises mais profundas de nossos modelos sugerem que, antes e depois da ado??o da IC, a intensidade das contribui??es de c?digo para uma release pode aumentar o tempo de entrega de PRs devido a uma maior carga de integra??o (em termos de commits integrados) da equipe de desenvolvimento. Finalmente, apresentamos heur?sticas capazes de identificar com precis?o os PRs que possuem um tempo de entrega prolongado. Nossos modelos de regress?o obtiveram valores de AUC mediano de 0.92 a 0.97. / Continuous Integration (CI) is a software development practice that leads developers to integrate their work more frequently. Software projects have broadly adopted CI to ship new releases more frequently and to improve code integration. The adoption of CI is usually motivated by the allure of delivering new software content more quickly and frequently. However, there is little empirical evidence to support such claims. Over the last years, many available software projects from social coding environments such as GitHub have adopted the CI practice using CI facilities that are integrated in these environments (e.g., Travis-CI). In this dissertation, we empirically investigate the impact of adopting CI on the time-to-delivery of pull requests (PRs), through the analysis of 167,037 PRs of 90 GitHub projects that are implemented in 5 different programming languages. On analyzing the percentage of merged PRs per project that missed at least one release prior being delivered to the end users, the results show that before adopting CI, a median of 13.8% of merged PRs are postponed by at least one release, while after adopting CI, a median of 24% of merged PRs have their delivery postponed to future releases. Contrary to what one might speculate, we find that PRs tend to wait longer to be delivered after the adoption of CI in the majority (53%) of the studied projects. The large increase of PR submissions after CI is a key reason as to why these projects deliver PRs more slowly after adopting CI. 77.8% of the projects increase the rate of PR submissions after adopting CI. To investigate the factors that are related to the time-to-delivery of merged PRs, we train linear and logistic regression models, which obtain sound median R-squares of 0.72-0.74, and good median AUC values of 0.85-0.90. A deeper analysis of our models suggests that, before and after the adoption of CI, the intensity of code contributions to a release may increase the delivery time due to a higher integration-load (in terms of integrated commits) of the development team. Finally, we are able to accurately identify merged pull requests that have a prolonged delivery time. Our regression models obtained median AUC values of 0.92 to 0.97.