Enregistré dans:
| Auteurs principaux: | , , , , |
|---|---|
| Format: | Preprint |
| Publié: |
2026
|
| Sujets: | |
| Accès en ligne: | https://arxiv.org/abs/2604.27754 |
| Tags: |
Ajouter un tag
Pas de tags, Soyez le premier à ajouter un tag!
|
| _version_ | 1866913076721221632 |
|---|---|
| author | Kumar, Amit Gandhi, Mahen Bhardwaj, Meher Ethari, Hrishikesh Agarwal, Sonali |
| author_facet | Kumar, Amit Gandhi, Mahen Bhardwaj, Meher Ethari, Hrishikesh Agarwal, Sonali |
| contents | Open-source projects often rely on a small group of highly active contributors known as hero developers. Prior work shows that hero developers are common in many OSS and enterprise projects, yet who qualifies as a hero depends heavily on the chosen contribution metric. Code-based metrics identify implementation-focused developers, whereas discussion-based metrics highlight coordination and communication; these metrics capture distinct facets of contribution. We conducted a measurement-sensitive study of multifaceted heroism across 77 Apache Software Foundation projects using three technical measures (commit count, distinct files touched, churn) and two social measures (issue-comment count, number of distinct issues commented on). We examined hero prevalence, overlap among hero sets, and severity-wise bug-fixing outcomes via fix and reopen rates. Results show that hero projects are common under all measures, but identified heroes differ substantially across facets. The pooled Jaccard overlap between technical and social hero sets is only 0.10. Cross-facet asymmetry is evident: 71.4% of technical heroes exhibit strong social activity, while only 24.2% of social heroes show strong technical activity. Fix-rate and reopen-rate differences are modest, yet hero-category rankings vary across severity levels and outcome measures. These findings indicate that heroism is not a single, metric-independent role. A multifaceted perspective offers a more reliable understanding of key contributors and better supports developer prioritisation and severity-aware bug assignment. |
| format | Preprint |
| id |
arxiv_https___arxiv_org_abs_2604_27754 |
| institution | arXiv |
| publishDate | 2026 |
| record_format | arxiv |
| spellingShingle | Multifaceted Hero Developers and Bug-Fixing Outcomes Across Severity Kumar, Amit Gandhi, Mahen Bhardwaj, Meher Ethari, Hrishikesh Agarwal, Sonali Software Engineering Open-source projects often rely on a small group of highly active contributors known as hero developers. Prior work shows that hero developers are common in many OSS and enterprise projects, yet who qualifies as a hero depends heavily on the chosen contribution metric. Code-based metrics identify implementation-focused developers, whereas discussion-based metrics highlight coordination and communication; these metrics capture distinct facets of contribution. We conducted a measurement-sensitive study of multifaceted heroism across 77 Apache Software Foundation projects using three technical measures (commit count, distinct files touched, churn) and two social measures (issue-comment count, number of distinct issues commented on). We examined hero prevalence, overlap among hero sets, and severity-wise bug-fixing outcomes via fix and reopen rates. Results show that hero projects are common under all measures, but identified heroes differ substantially across facets. The pooled Jaccard overlap between technical and social hero sets is only 0.10. Cross-facet asymmetry is evident: 71.4% of technical heroes exhibit strong social activity, while only 24.2% of social heroes show strong technical activity. Fix-rate and reopen-rate differences are modest, yet hero-category rankings vary across severity levels and outcome measures. These findings indicate that heroism is not a single, metric-independent role. A multifaceted perspective offers a more reliable understanding of key contributors and better supports developer prioritisation and severity-aware bug assignment. |
| title | Multifaceted Hero Developers and Bug-Fixing Outcomes Across Severity |
| topic | Software Engineering |
| url | https://arxiv.org/abs/2604.27754 |