A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
Dieses Paper führt eine kuratierte, hochpräzise globale Autoren-Identitäts-Map für die World of Code (V2604) ein, die 106,8 Millionen Autoren-Strings in 62,7 Millionen kanonische Identitäten über 5,87 Milliarden Commits auflöst, indem sie der Vermeidung fehlerhafter „Clumping“-Effekte gegenüber dem einfachen Recall Vorrang einräumt und dadurch die Zuverlässigkeit groß angelegter Software-Repository-Analysen sowie wissenschaftlicher Autoren-Graph-Joins signifikant verbessert.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich die gesamte Geschichte der Softwareentwicklung als eine riesige, chaotische Bibliothek mit fast 6 Milliarden Büchern (Code-Commits) vor. In dieser Bibliothek unterschreibt jeder, wenn er eine Seite schreibt, mit seinem Namen. Aber hier liegt das Problem: Die Unterschriften sind ein Chaos.
Eine Person unterschreibt einmal als „Jane Doe“, dann als „j.doe“, dann als „jane.doe@work.com“ und später als „jane@personal.org“. Gleichzeitig unterschreiben tausende verschiedene Fremde ihre Seiten einfach als „root“, „user“ oder „Ihr Name“.
Wenn Sie versuchen würden, die Anzahl der einzigartigen Autoren zu zählen, indem Sie nur nach diesen Unterschriften schauen, würden Sie ein völlig falsches Ergebnis erhalten. Sie würden denken, es gäbe Millionen mehr Menschen, als es tatsächlich gibt (weil eine Person wie zehn aussieht), oder Sie würden übersehen, dass viele dieser „Personen“ in Wirklichkeit Roboter oder Bots sind.
Dieses Paper präsentiert eine Riesige Identitäts-Map, die diese Bibliothek bereinigt. Sie nimmt 106 Millionen chaotische Unterschriften und ordnet sie 62,7 Millionen echten Menschen zu.
So haben sie es gemacht, erklärt anhand einfacher Analogien:
1. Das Problem: Die „Mega-Cluster“-Falle
Die Autoren erklären, dass frühere Versuche, dieses Problem zu lösen, so waren, als würde man versuchen, Puzzleteile allein basierend auf der Farbe zusammenzukleben. Wenn man einfach sagt: „Wenn zwei Namen einen gemeinsamen Buchstaben oder eine E-Mail teilen, müssen sie dieselbe Person sein“, klebt man unweigerlich Millionen unbeteiligter Menschen zu einem einzigen, monströsen Klumpen zusammen.
Sie nennen das einen „Mega-Cluster“. Stellen Sie sich eine Bibliothek vor, in der der Bibliothekar entschieden hat, dass jedes einzelne Buch im Gebäude vom selben Autor geschrieben wurde, nur weil alle das Wort „Der“ im Titel verwendeten. Genau das passierte in früheren Maps: Sie verschmolzen versehentlich 3 Millionen verschiedene Entwickler zu einem einzigen „Super-Autor“.
2. Die Lösung: Eine sechsstufige Detektiv-Pipeline
Um dies zu beheben, entwickelten die Autoren einen sechsstufigen Detektiv-Prozess, um die Unterschriften zu sortieren, ohne diesen riesigen Fehler zu begehen:
- Schritt 1: Der erste Hinweis: Sie beginnen damit, Unterschriften zu verknüpfen, die offensichtliche Gemeinsamkeiten aufweisen, wie etwa die exakt gleiche E-Mail-Adresse.
- Schritt 2: Der „Bad Actor“-Filter: Sie ignorieren Namen, die eindeutig generisch sind (wie „root“ oder „admin“) oder zu Robotern gehören. Dies sind wie „Geister“ in der Bibliothek; sie sollten nicht dazu verwendet werden, echte Menschen miteinander zu verbinden.
- Schritt 3: Der strukturelle Schnitt (Der magische Trick): Dies ist der wichtigste Schritt. Sie betrachteten die Verbindungen wie eine Landkarte von Brücken. Sie fanden einige spezifische „Brücken-Unterschriften“, die riesige, unzusammenhängende Gruppen von Menschen zusammenhielten. Sie kappten diese Brücken. Dies löste den riesigen „Mega-Cluster“ augenblicklich in kleinere, handhabbare Gruppen auf.
- Schritt 4: Der intelligente Klassifizierer: Sie nutzten ein Computerprogramm (das auf Millionen echter Beispiele trainiert wurde), um zu entscheiden, ob zwei ähnlich klingende Namen tatsächlich dieselbe Person sind oder nur ein Zufall (wie zwei Personen namens „John Smith“).
- Schritt 5: Die Wiederherstellung des Recall: Nachdem sie die schlechten Verbindungen gekappt hatten, fügten sie vorsichtig einige Verbindungen wieder hinzu, die sie zuvor ignoriert hatten, indem sie eine andere Methode verwendeten (die Betrachtung, wie Namen in Häppchen geschrieben werden), um sicherzustellen, dass sie nicht zu viele echte Bekannte übersehen hatten.
- Schritt 6: Die finale Kennzeichnung: Sie wählten die „beste“ Version jedes Namens (meistens die mit einem echten Namen und einer echten E-Mail), um die offizielle ID für diese Person festzulegen.
3. Warum das wichtig ist: Der „Bus-Faktor“ und die Produktivität
Das Paper zeigt, dass Ihre Mathematik fehlerhaft ist, wenn Sie die Namen nicht korrigieren. Sie führten mehrere Experimente durch, um den Unterschied aufzuzeigen:
- Zählen von Menschen: Ohne die Korrektur der Namen sieht die Bibliothek so aus, als hätte sie 66 % mehr Autoren, als sie tatsächlich hat. Es ist, als würde man dieselbe Person 10-mal zählen, weil sie sich auf 10 verschiedene Arten unterschrieben hat.
- Teamsicherheit (Der Bus-Faktor): Stellen Sie sich ein Projekt vor, bei dem Sie wissen müssen: „Wenn eine Person von einem Bus angefahren wird, stirbt dann das Projekt?“
- Ohne die Korrektur der Namen: Das Projekt sieht sicher aus, weil die Arbeit auf 10 verschiedene „Namen“ verteilt ist.
- Mit der Korrektur der Namen: Sie erkennen, dass alle 10 Namen zu einer Person gehören. Das Projekt ist in Wahrheit in großer Gefahr.
- Das Ergebnis: Das Paper fand heraus, dass 96 % der Projekte tatsächlich von einer einzigen Person abhängen (ein „Single Point of Failure“), während die unordentlichen Daten es so aussehen ließen, als wären es nur 90 %.
- Zentralität (Die „wichtigsten“ Personen): In den unordentlichen Daten waren die „wichtigsten“ Personen im Netzwerk oft Roboter oder generische Konten (wie „root“). Sobald sie die Namen korrigierten, waren die „wichtigsten“ Personen tatsächliche menschliche Entwickler.
4. Der „Goldstandard“-Check
Die Autoren haben nicht nur geraten; sie haben ihre Map gegen zwei verschiedene „Antwortschlüssel“ getestet:
- Menschliche Überprüfung: Eine kleine Gruppe von Menschen prüfte, ob die Map korrekt war.
- GitHub-Daten: Sie nutzten Daten aus GitHub-Konten, um zu sehen, ob sie alle Aliase gefunden hatten.
Sie fanden heraus, dass ihre neue Map eine Präzision von 88 % aufweist (sie verwechselt selten Fremde) und eine Vollständigkeit von 70 % besitzt (sie findet die meisten Aliase). Entscheidend war, dass sie bewiesen, dass die alten Maps nur deshalb perfekt aussah (95 % Präzision), weil sie die riesigen „Mega-Cluster“ ignorierten, in denen sich die Fehler verbargen.
5. Verbindung von Code und Wissenschaft
Abschließend schlägt das Paper vor, dass diese Map als „universeller Schlüssel“ dienen kann, um Softwareentwickler mit akademischen Forschern zu verbinden. Da viele Menschen sowohl Code als auch wissenschaftliche Arbeiten schreiben, könnte diese Map helfen, die Code-Arbeit einer Person mit ihren Forschungsarbeiten zu verknüpfen. Sie warnen jedoch davor, dass dies sehr schwierig ist, da Namen so häufig vorkommen (z. B. „John Smith“ im Code und „John Smith“ in einem Paper), und man äußerst vorsichtig sein muss, nicht versehentlich die falschen Personen zu verknüpfen.
Zusammenfassung
Das Paper ist ein Leitfaden zur Bereinigung einer massiven, chaotischen Datenbank von Software-Autoren. Es beweist, dass das Ignorieren des Chaos zu falschen Schlussfolgerungen führt – darüber, wer arbeitet, wie produktiv sie sind und wie sicher Projekte sind. Ihre neue Map ist die erste, die erfolgreich vermeidet, die Falle zu umgehen, Millionen von Fremden zu einem einzigen, falschen Identitätsklumpen zusammenzukleben.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.