Preprocessed data for find motives behind cross-platform forks from SWHGD dataset
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
The fork-based development mechanism provides the flexibilityand the unified processes for software teams to collaborate easilyin a distributed setting without too much coordination overhead.Currently, multiple social coding platforms support fork-based de-velopment, such as GitHub, GitLab, and Bitbucket. Although thesedifferent platforms virtually share the same features, they havedifferent emphasis. As GitHub is the most popular platform and thecorresponding data is publicly available, most of the current stud-ies are focusing on GitHub hosted projects. However, we observedanecdote evidences that people are confused about choosing amongthese platforms, and some projects are migrating from one platformto another, and the reasons behind these activities remain unknown.With the advances of Software Heritage Graph Dataset (SWHGD),we have the opportunity to investigate the forking activities acrossplatforms. In this paper, we conduct an exploratory study on 10popular open-source projects to identify cross-platform forks andinvestigate the motivation behind. Preliminary result shows thatcross-platform forks do exist, for the 10 subject systems in thisstudy, we found 81,357 forks in total among which 179 forks areon GitLab. Based on our qualitative analysis we found that most ofthe cross-platform forks that we identified are mirrors of anotherplatform, but we still find cases that were created due to preferenceof using certain functionalities (e.g. Continuous Integration(CI))supported by different platforms. This study lays the foundation offuture research directions, such as understanding the differencesbetween platforms and supporting cross-platform collaboration.
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.
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,001 | 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,000 | 0,000 |
| Études des sciences et des technologies | 0,002 | 0,000 |
| Communication savante | 0,006 | 0,001 |
| Science ouverte | 0,014 | 0,011 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,001 | 0,008 |
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écoule