Open-Science,
une expérience sur GitHub

Dan Chaltiel

Team Oncostat, Gustave Roussy

Open science

Petite introduction

Définition INSERM 2019 (lien)

La science ouverte, ou open science, est un mouvement dont l’objectif est de rendre universellement accessibles les résultats de la recherche scientifique (publications et données de recherche, notamment).

But: publier avec l’article les données et le code d’analyse, de manière à ce que n’importe qui puisse reproduire nos résultats.

Fakemed

On entend de plus en plus parler de fraudes et publications falsifiées.

• Beaucoup de lanceurs d’alerte, quelques retraits d’articles, très peu de mesures disciplinaires…

• “Paper mills”, les industries des fausses publications (plus d’infos dans nature, mdpi, lqdm, …)

• Pas forcément de la malhonnêteté : le publish or perish pousse à publier vite. Prendre le temps de tout vérifier n’est pas valorisé partout.

Fakemed

Quand partager les données et le code d’analyse avec un article sera la norme,

• il sera plus compliqué de falsifier les études.

• on se rendra compte plus vite d’éventuelles erreurs et biais dans les études.

Le code n’étant pas reviewé, c’est effrayant de le publier. On reste humains et on fait forcément des erreurs de code.

Au final, la qualité globale de la science sera forcément augmentée!

Video

BONUS: même sans erreurs, il y a les problèmes inhérents à la méthode scientifique : risques alpha/beta, biais multiples…

Super vidéo de 12 minutes (3m07) Allez voir toutes ses autres vidéos :-)

Elisabeth Bik

Suivez Elisabeth Bik sur tweeter! @MicrobiomDigest

Git et GitHub

Enfin, on y vient!

Définitions

GitHub est une plateforme d’hébergement de code pour la gestion de versions et la collaboration. Cette plateforme vous permet de travailler avec d’autres personnes sur des projets depuis n’importe où. (source)

En pratique, GitHub est un Hub de dépots Git.

Commençons déjà par expliquer ce qu’est Git.

Et ce n’est pas forcément facile d’expliquer Git…

Git

Git est un système de contrôle de version (VCS).

Imaginons un projet contenant des données, du code, des figures, des rapports…

• Git va permettre de faire des “photographies” du projet à un instant t , appelé commits.

• Chaque commit est ajouté à une base de données interne.

• On peut synchroniser cette base de données à un serveur centralisé (e.g. GitHub).

Plus d’infos sur le modèle sur http://shafiul.github.io/gitbook/1_the_git_object_model.html

En pratique la puissance de git va bien au delà de ce que je vais raconter ici mais ça nous suffira pour commencer.

Commits

Chaque commit contient l’information de tous les fichiers changés (diff), l’auteur, et une petite description des changements.

Git en pratique

Parce que j’imagine que c’est encore un peu flou…

Mise en place

On va avoir besoin de plusieures choses :

• Un dossier “racine” local qui contient la totalité du projet
• Une interface d’édition : Notepad++, PyCharm, RStudio…
• Avoir installé Git (lien ici)
• Une interface graphique pour Git

pour Jupyter ça dépend, il faut bien que les fichiers soient en local. Pareil pour RStudio server.

Exemple

Prenons l’exemple de mon package crosstable pour R.

Instant publicité: package que je développe depuis 2020, une sorte de table_1 ou gt_summary, optimisé dans l’interface avec Word pour faire des rapports automatisés. Si vous avez l’occasion de l’utiliser et que vous avez des idées d’amélioration, contactez-moi :-)

Bref.

Ici, interace RStudio standard (enfin, en dark-mode), on voit l’arborescence en bas-droite. Mon dossier racine F:/GITHUB/crosstable contient tout le projet

La présentation tient évidemment aussi pour un projet non-package et même non-R : étude épidémio, étude stats de simulation, pipelines…

Git client

Les puristes utilisent Git en ligne de commande, mais nous on va utiliser un logiciel avec une GUI.

Ici, j’utilise GitHub Desktop :

RStudio propose une GUI pour Git mais je la trouve très peu ergonomique. Il y a aussi GitKraken, TortoiseGit, SourceTree, MaGit… J’ai testé plusieurs softwares et pour ce que j’en fais GD est le meilleur, surtout quand le remote est GitHub.

Cas pratique : setup

Petit cas pratique d’utilisation :

• J’en suis au 855ème commit sur mon projet crosstable.

• J’ai fait quelques modifications sur RStudio

• Ces modifications concernent deux points : le fichier NAMESPACE et les tests

• On va aller sur GitHub Desktop pour faire un commit.

Cas pratique : Commit & Push

1. 6 fichiers ont été modifiés depuis le dernier commit. On choisit lesquels inclure dans le prochain commit.
2. Pour chaque fichier, on peut voir la “diff”, càd les ajouts/suppressions et sélectionner les lignes pour le commit
3. On commit les changements sélectionnés, avec un petit message.
4. on push les commits locaux sur le serveur origine (ici Github mais on peut faire mieux)

Cas pratique : Historique

J’ai 4 commits non synchronisés. Dans mon plus récent, j’ai changé 3 fichiers, avec +3 lignes et -5 lignes. On voit que dans NAMESPACE j’ai juste supprimé 2 lignes.

Si j’avais vraiment été au bout de mon exemple, on verrait un 5ème commit non synchronisé.

Remote (GitHub web)

Dépot centralisé de mes commits (si pushed), ici hébergé sur https://github.com:

N’importe qui peut cliquer sur <> Code > Download zip et télécharger le projet entier. Avec GitHub Desktop c’est encore plus simple. Attention, tout l’historique est visible par tout le monde, n’écrivez pas trop de bêtises dans vos commits :-) https://www.scitepress.org/Papers/2022/110397/110397.pdf

Conclusion sur Git

• Git permet de gérer les versions

• Evite d’avoir 6 copies de projet_v3_final_pour_de_vrai_cette_fois

• Utile pour les petits et les grands projets

Grâce à GitHub, on va pouvoir publier nos codes et utiliser Git dans des projets collaboratifs.

Encore une fois, ça pourrait être un autre service que GitHub Par exemple GitLab, ou même un dossier GIT sur une dropbox!

Travail collaboratif

Github est surtout un formidable outil de collaboration, particulièrement adapté à l’encadrement.

Espace collaboratif

En plus du versionning, GitHub c’est :

• Un outil de partage de code

• Mais c’est surtout un espace collaboratif très puissant :

  • Entre programmeurs
  • Avec les utilisateurs

• Pas forcément open-source (on peut garder un repo private)

Git est un très mauvais outil de management, le nombre de commits ou de changes est un mauvais marqueur d’efficacité!

Si c’est un projet de recherche pure, les utilisateurs peuvent être les lecteurs de l’article

Collab

1. On clone le projet (repository). ~= on DL le .zip
2. On travaille sur sa working copy, on fait des commits
3. On push ces commits vers le serveur
4. Quelqu’un d’autre travaille sur son propre clone
5. On pull ses commits sur le notre

14. On recommence!

Problème : et si plusieurs personnes font un commit et pushent en même temps ?

Conflits

Si deux personnes travaillent en parallèle à partir du même commit, on peut résoudre les conflits très facilement.

Pas trouvé de capture d’écran sur GitHub Desktop mais c’est pareil. Facile techniquement, mais quand même tedious

Readme

La page d’accueil d’un dépot Github a souvent un fichier README.md. C’est un fichier markdown qui présente le projet. En général ça couvre l’installation et l’utilisation basique. On peut en mettre même dans des sous-dossiers.

Issues

Système de tickets pour qu’un utilisateur externe signale un bug ou une amélioration.

Attention, pas de modération !

Pull-requests

Le projet est publique, donc tout le monde peut voir le code N’importe qui peut alors proposer une modification du code : ajout de feature, correction de bug, de typo… Le propriétaire peut accepter les modifs en un clic, et il y a une interface de review

Actions

Ma fonction préférée ! Utilisation des serveurs de GitHub pour les tâches répétitives.

J’ai 5 actions sur mon repo : un qui lance R-CMD-Check pour vérifier que mon package est valide pour le CRAN un qui fabrique la documentation un qui déploie la documentation sur la github page (ça fait doublon non?) un qui fait le test-coverage et un qui bump le numéro de version https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration

Actions (simulations)

Projet : faire ses simulations sur GitHub

• 6h par job, 35 jours par workflow, 20 jobs en parallèle

• queue de 500 workflows

• job matrix de max 256 jobs

• Encore plus avec un compte pro (lien)

Je pense tester bientôt. Je crois que c’est en accord avec les Terms de GitHub: https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features#actions

Documentation website

Exemple: https://danchaltiel.github.io/crosstable/

Tout ça est automatiquement généré par R à partir du Readme, des vignettes, et des manuals (package pkgdown). Le site est hébergé par “github pages” sur https://danchaltiel.github.io/crosstable/.

Questions ouvertes

• Confidentialité des bases de données, RGPD ?

• Modération des issues

• Utiliser GitHub plutôt que GitLab, FramaGit, …

  • Un jour une solution indépendante ?

Issues -> risque de devenir une plateforme de review sauvage

GitHub appartient à Microsoft –> Copilot

Software Heritage

We collect and preserve software in source code form, because software embodies our technical and scientific knowledge and humanity cannot afford the risk of losing it.

• Collecte massive sur GitHub, permet l’archivage pérenne des codes sources.

• Non exhaustif : s’inscrire ici pour s’assurer que son code est sauvegardé.

Sauvegardé même si GitHub disparait. https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/DanChaltiel/crosstable

Merci de votre attention

N’hésitez pas si vous avez des questions.

N’hésitez pas à tester les programmes

Tags/Releases

Blame

Très utile pour trouver des bugs!