Internal quality assurance for external contributions in GitHub: An empirical investigation

Abstract

For popular open‐source software projects, there are always a large number of worldwide developers who have been glued to making code contributions, while most of these developers play the role of casual contributors because of their very limited code commits. The frequent turnover of such a group of developers and the wide variations in their coding experiences challenge the project management on code and quality. This paper aims to investigate the status quo of internal quality assurance for external contributions in social coding sites. We first conducted a case study of 21 popular GitHub projects to estimate the code quality of the casual contributors. The quantitative results show that the casual contributors introduced greater quantity and severity of code quality issues than the main contributors; the developers who contribute to different projects as main and casual contributors did not perform significantly differently in terms of their code quality. On the basis of these findings, we further conducted a survey of 81 developers on GitHub to understand their practices on internal quality assurance. The qualitative results expose some limitations of present internal quality control for external contributions in GitHub. Finally, we discuss an alternative quality management paradigm: Continuous Inspection for industrial practices.

Studying in the ‘Bazaar’: An Exploratory Study of Crowdsourced Learning in GitHub

“…The quality theme also permeates a number of challenges (32% of all reported challenges). As the collective intelligence creates high-quality content, the wide variations among the crowd's knowledge levels challenge the quality management of the massive number of contributions [34]. Moreover, assessing the quality of content and knowledge is much more difficult than assessing the quality of code in the OSS context.…”

History-Driven Fix for Code Quality Issues

“…They proposed a defect classification scheme in order to enumerate the types of defects that can be identified by static tools, and concluded that automated code inspection faults can be used as efficient predictors of failures. Yao Lu et al investigated internal quality of the code made by casual Contributors in OSS projects within GitHub [2]. They proposed a method to estimate developers' code quality using the ''Code Quality Issue Density (CQID)'' metric and concluded that casual contributors tend to introduce a greater quantity of CQIs with greater severity than the main contributors and casual contributors tend to introduce CQIs on coding convention, errorhandling, CWE (Common Weekness Enumeration) and brain-overload, which can decline the readability, reliability, efficiency and testability of the software.…”

“…Generally, code quality can be classified as internal and external quality attributes [4]. The external quality attributes are reflected at runtime stage such as functionality and correctness, while internal quality attributes exist in development and maintenance [2], which is concerned by developers, such as maintainability and readability. High internal quality source code not only improves the readability of code and help developers quickly understand explicit and implicit meanings expressed by code, but also reduces the risk of crash and the cost of software maintenance [7].…”

“…casually submit a very limited number of violation fixes and feature enhancements [2]. According to The State of the Octoverse 2018 [8], the GitHub community reached 31 million developers working across 96 million repositories.…”

“…As a result, Continuous Inspection for Pull-based contributions are required in OSS community, which automatically utilizes static analysis tool to detect CQIs. Continuous Inspection provides continuous code quality management that incorporates shorter feedback loops to ensure the rapid resolution of quality issues [2]. Nowadays developers usually manually fix CQI when executing Continuous Inspection, including understanding CQI Rule, searching for proper fix solution, and revising source code which is very time-consuming.…”