Good or Bad Committers? A Case Study of Committers' Cautiousness and the Consequences on the Bug Fixing Process in the Eclipse Project

Jongyindee, Anakorn; Ohira, Masaichi; Ihara, Akinori; Matsumoto, Kenichi

doi:10.1109/iwsm-mensura.2011.24

Cited by 5 publications

(5 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The transparent nature and social media attached to the project development platforms such as GitHub and SourceForge.NET also led developers to become extremely aware that their contribution actions had an audience and therefore focused on the number of contributions rather than the quality of the contribution. Although these models can help in understanding how a developer is promoted to a committer role, there have been few studies that use survey methods to subjectively measure developer perceptions that influence their contribution behaviour [10,[36][37][38][39]. This suggests the potential use of surveys to understand individual developer involvement with the blockchain project.…”

Section: Committer Assessment Practice Overviewmentioning

confidence: 99%

Comparative Performance of Machine Learning Algorithms for Predicting Future Committer in Blockchain Projects

Alawiyah Abd Wahab,

Huda H. Ibrahim,

Shehu M. Sarkintudu

et al. 2023

ARASET

View full text Add to dashboard Cite

The success of blockchain projects depends, to a large extent, on the developer's involvement. Source code-commit privilege to the project is typically restricted to a few developers known as committers. Project leaders continuously search for new committers to evolve into a high-quality blockchain. However, promoting developers into committers is risky, mainly when the promoted committers exhibit low involvement behaviour. Hence, the committer assessment process is critical to the successful evolution of blockchain projects. The phenomenon of developer induction as code committers has previously been explored in the literature. However, previous studies employed objective measures such as the number of bugs report and code patches to appraise the developers activities for promotion purposes. Although these approaches are significant, behavioural tendencies influencing developers' activities are ignored. There have, however, been comparatively few investigations on a subjective measure that evaluate developers' perception of their activities for promotion purposes. This study aims to appraise blockchain developers' perceptions for predicting future committers in blockchain projects. In this study, 173 blockchain developers’ perceptions were gathered. The study employed hybrid analyses such as Structural Equation Modelling (SEM) to first analyse the survey data and Machine Learning (ML) algorithms to predict future committers. The performance of various ML algorithms was evaluated compared to classification performance indicators such as the F1 score, accuracy, precision, and AUC. In addition, the study also investigates the most important factors that predict future committers. The results indicate that XGBoost algorithm achieves the best performance with an accuracy of 0.94. Moreover, the most important factors in predicting future committers in a blockchain project are project desertion, developer involvement, decision-right delegation and system integration.

show abstract

Section: Committer Assessment Practice Overviewmentioning

confidence: 99%

Comparative Performance of Machine Learning Algorithms for Predicting Future Committer in Blockchain Projects

Alawiyah Abd Wahab,

Huda H. Ibrahim,

Shehu M. Sarkintudu

et al. 2023

ARASET

View full text Add to dashboard Cite

show abstract

“…Capable people are always the key to the success [32]. However, for largescale projects it is difficult to identify developers with good potential to become committers [31], we therefore proposed an approach to select committers.…”

Section: Selection Of Candidate Committersmentioning

confidence: 99%

Scaling open source communities

Tan

Zhou

Fitzgerald

2020

Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering

View full text Add to dashboard Cite

show abstract

“…Jongyindee et al (2011) found that bugs fixed by more experienced developers are less likely to be reopened.…”

Section: Bug Reopeningmentioning

confidence: 99%

“…Regarding the impact of reopened bugs, the literature reports reopening rates as low as 1.4 % (Almossawi 2012) and as high as 11.7 % (Jongyindee et al 2011), obtained from open source projects. Also, reopened bugs are said to have a life cycle from 2 to 5 times higher (Jongyindee et al 2011;Shihab et al 2010) than regular bugs, and to involve the participation of 40 % more developers (Jongyindee et al 2011).…”

Section: Bug Reopeningmentioning

confidence: 99%

“…Also, reopened bugs are said to have a life cycle from 2 to 5 times higher (Jongyindee et al 2011;Shihab et al 2010) than regular bugs, and to involve the participation of 40 % more developers (Jongyindee et al 2011). Park et al (2012) studied bug fixes with programming errors that led to the creation of supplementary bug fixes, i.e., new, improved fixes for the same bug.…”

Section: Bug Reopeningmentioning

confidence: 99%

See 1 more Smart Citation

Patch rejection in Firefox: negative reviews, backouts, and issue reopening

Souza

Chávez

Bittencourt

2015

J Softw Eng Res Dev

View full text Add to dashboard Cite

Background: Writing patches to fix bugs or implement new features is an important software development task, as it contributes to raise the quality of a software system. Not all patches are accepted in the first attempt, though. Patches can be rejected because of problems found during code review, automated testing, or manual testing. A high rejection rate, specially later in the lifecycle, may indicate problems with the software development process. Our objective is to better understand the relationship among different forms of patch rejection and to characterize their frequency within a project. This paper describes one step towards this objective, by presenting an analysis of a large open source project, Firefox. Method: In order to characterize patch rejection, we relied on issues and source code commits from over four years of the project's history. We computed monthly metrics on the occurrence of three indicators of patch rejection-negative code reviews, commit backouts, and bug reopening-and measured the time it takes both to submit a patch and to reject inappropriate patches. Results: In Firefox, 20 % of the issues contain rejected patches. Negative reviews, backouts, and issue reopening are relatively independent events; in particular, about 70 % of issue reopenings are premature; 75 % of all inappropriate changes are rejected within four days. Conclusions: Patch rejection is a frequent event, occurring multiple times a day. Given the relative independence of rejection types, existing studies that focus on one single rejection type fail to detect many rejections. Although inappropriate changes cause rework, they have little effect on the quality of released versions of Firefox.

show abstract

Good or Bad Committers? A Case Study of Committers' Cautiousness and the Consequences on the Bug Fixing Process in the Eclipse Project

Cited by 5 publications

References 22 publications

Comparative Performance of Machine Learning Algorithms for Predicting Future Committer in Blockchain Projects

Comparative Performance of Machine Learning Algorithms for Predicting Future Committer in Blockchain Projects

Scaling open source communities

Patch rejection in Firefox: negative reviews, backouts, and issue reopening

Contact Info

Product

Resources

About