Was It Never Collected, or Rewritten Away? A Commit-Provenance Dataset Separating Ingestion Gaps from Upstream History Edits across the World of Code
Cet article introduit un ensemble de données de provenance des commits qui distingue les commits manquants causés par des réécritures de l'historique amont (force-pushes) de ceux résultant de véritables lacunes d'ingestion dans les miroirs de code mondiaux, révélant qu'environ 6,5 % des commits manquants sont réécrits plutôt que perdus et fournissant des facteurs de correction pour améliorer la précision du comptage des contributions et du reporting sur l'exhaustivité des miroirs.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez que vous essayiez de tenir un album photo parfait et complet de chaque instant d'un projet artistique mondial massif où des milliers de personnes peignent, effacent et repeignent constamment par-dessus le travail des autres.
Ce document traite d'un nouvel outil qui nous aide à comprendre pourquoi certaines photos manquent à notre album.
Le Problème : Le mystère de la « photo manquante »
Pendant des années, des chercheurs ont tenté de collecter chaque commit (une « photo » des changements de code) de GitHub dans une immense base de données appelée World of Code (WoC). Mais ils ont remarqué un problème : l'album est incomplet. Il manque des millions de « photos » qui auraient dû s'y trouver.
Auparavant, les chercheurs supposaient simplement que ces photos étaient perdues à jamais parce que le système de collecte avait échoué. Ils pensaient : « Oh, nous avons manqué 40 % des photos ; notre collecte est défaillante. »
Mais ce document soutient : Attendez une minute. Peut-être que les photos ne sont pas perdues ; peut-être ont-elles été supprimées intentionnellement.
Les deux suspects
L'auteur, Audris Mockus, identifie deux raisons très différentes pour lesquelles une photo pourrait manquer :
- L'écart de collecte (Le « cliché manqué ») : La caméra (le système de collecte) a cligné des yeux, ou le transfert de fichier a échoué, et la photo n'a jamais été enregistrée. C'est une véritable erreur.
- La réécriture de l'historique (Le « brouillon supprimé ») : L'artiste (le propriétaire du projet) a décidé qu'il n'aimait pas une version spécifique de la peinture. Il a utilisé un « force-push » (une gomme numérique) pour effacer cette version de l'historique et la remplacer par une nouvelle. La photo n'a jamais existé dans la version finale car l'artiste l'a effacée.
L'ancienne méthode de comptage regroupait ces deux cas. Elle disait : « Il nous manque 46 % des photos ! » Cela faisait paraître la collecte bien pire qu'elle ne l'était réellement.
Le travail de détective : Deux points de vue différents
Pour résoudre ce mystère, l'auteur a utilisé deux « caméras » différentes pour observer le même événement :
- Caméra A (GHArchive) : C'est comme une caméra de surveillance qui enregistre tout ce qui a été annoncé au moment où cela se produit. Elle ne se soucie pas de savoir si une photo est supprimée plus tard ; elle enregistre simplement : « À 14h00, quelqu'un a publié une photo appelée 'Commit X'. »
- Caméra B (World of Code) : C'est l'album photo actuel. Il contient tout ce qu'il a collecté jusqu'à présent, mais il ne conserve pas les photos supprimées.
En comparant le journal de la caméra de surveillance (ce qui a été annoncé) avec l'album actuel (ce qui est conservé), l'auteur a pu trier chaque photo manquante en trois piles nettes :
- Présente : La photo est dans l'album. (53 % du temps)
- Réécrite : La photo a été annoncée, mais l'artiste l'a effacée plus tard. La caméra de surveillance l'a vue, mais l'album ne l'a pas car elle a été supprimée. (6,5 % du temps)
- Jamais ingérée : La photo a été annoncée, l'artiste ne l'a pas supprimée, mais l'album ne l'a toujours pas. C'est le véritable écart de collecte. (40 % du temps)
La grande surprise
Les résultats ont été choquants. Auparavant, on pensait que le taux de « perte » était de près de 47 %.
- La réalité : Seuls 40 % sont réellement manquants (écarts de collecte).
- Le rebondissement : Environ 6,5 % des photos « manquantes » étaient en fait supprimées par les artistes eux-mêmes.
Cela signifie que pour 15 photos manquantes, une d'entre elles n'était pas une erreur du collecteur ; c'était une édition délibérée du projet.
Pourquoi cela importe (en termes simples)
1. Un rapport honnête
Si vous étudiez le logiciel, vous n'avez plus besoin de dire : « Nos données sont incomplètes à 47 %. » Vous pouvez dire : « Nos données sont incomplètes à 40 %, et les 7 % restants ont été supprimés par les créateurs. » Cela rend votre étude beaucoup plus précise.
2. Compter le travail correctement
Imaginez un travailleur qui écrit 100 lignes de code, puis les supprime et les réécrit sous forme de 100 nouvelles lignes.
- Ancien compte : Vous ne voyez que les 100 nouvelles lignes. Vous pensez qu'il a fait 100 lignes de travail.
- Nouveau compte : Cet outil voit qu'il a écrit 100 lignes, les a supprimées, puis en a écrit 100 autres. Il réalise que les 100 lignes « supprimées » étaient un travail réel qui a juste été caché.
- Le résultat : Le document montre que si vous ne comptez que ce qui est actuellement visible, vous sous-estimez la productivité totale d'environ 10,8 %. C'est comme penser qu'une usine a fabriqué 90 voitures alors qu'elle en a fabriqué 100, parce que 10 ont été mises au rebut et reconstruites.
3. Éviter le double comptage
Si un développeur réécrit un commit (efface le précédent et crée un nouveau avec un nouvel ID), il s'agit du même « patch » de code. Sans cet outil, un ordinateur pourrait compter l'ancienne version et la nouvelle version comme deux contributions distinctes. Cet outil signale ces doublons pour ne pas vous induire en erreur.
L'essentiel
Ce document nous donne une loupe de détective. Il sépare le « cliché manqué » (écarts de collecte) de la « réécriture d'historique » (versions supprimées).
Il nous indique que le World of Code est en réalité meilleur pour collecter des données qu'on ne le pensait (car une partie des données « manquantes » n'était pas censée être là), mais il nous indique aussi que nous sous-estimons la quantité de travail accomplie par les développeurs car nous ne voyons pas le travail qu'ils ont effacé.
L'auteur a rendu publiques toutes les données et tous les outils afin que quiconque puisse utiliser cette « lentille de détective » pour obtenir une image plus claire et plus honnête du monde du code.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.