Replication Package - Understanding the Time to First Response In GitHub Pull Requests
Notice bibliographique
Résumé
The pull-based development is widely adopted in<br> modern open-source software (OSS) projects, where developers<br> propose changes to the codebase by submitting a pull request<br> (PR). However, due to many reasons, PRs in OSS projects<br> frequently experience delays across their lifespan, including<br> prolonged waiting times for the first response. Such delays<br> may significantly impact the efficiency and productivity of the<br> development process, as well as the retention of new contributors<br> as long-term contributors.<br> In this paper, we conduct an exploratory study on the time-to-<br> first-response for PRs by analyzing 111,094 closed PRs from ten<br> popular OSS projects on GitHub. We find that bots frequently<br> generate the first response in a PR, and significant differences<br> exist in the timing of bot-generated versus human-generated<br> first responses. We then perform an empirical study to examine<br> the characteristics of bot- and human-generated first responses,<br> including their relationship with the PR’s lifetime. Our results<br> suggest that the presence of bots is an important factor contribut-<br> ing to the time-to-first-response in the pull-based development<br> paradigm, and hence should be separately analyzed from human<br> responses. We also report the characteristics of PRs that are more<br> likely to experience long waiting for the first human-generated<br> response. Our findings have practical implications for newcomers<br> to understand the factors contributing to delays in their PRs.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,002 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,002 |
| Études des sciences et des technologies | 0,002 | 0,000 |
| Communication savante | 0,002 | 0,000 |
| Science ouverte | 0,004 | 0,003 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,003 | 0,112 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; les deux têtes enseignantes s’accordent sur ce qui est montré ici.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».