SAMOURAÏ COOP
Démarrer un projet

FRPar Samouraï Coop5 min

Reportz : qui construit les communs numériques, en direct depuis GitHub

Le tableau Reportz sur La Suite numérique : une année de pull requests fusionnées en histogramme, au-dessus des compteurs de contributeurs actifs, de PR fusionnées, d’organisations et de contributeurs depuis le début

Les administrations publiques se sont mises à publier du logiciel libre sérieux. La Suite numérique, créée et opérée par la DINUM, est « utilisée chaque mois par plus de 500 000 agents, dans 15 ministères et de nombreuses administrations », selon ses propres mots. Une grande partie est construite à ciel ouvert sur github.com/suitenumerique — Docs, Visio, Messagerie et Fichiers y sont tous. D’autres vivent ailleurs : Tchap a sa propre organisation, FranceTransfert est sous numerique-gouv, et Grist est un amont tiers que la Suite adopte plutôt qu’elle n’écrit.

Ce qui pose une question à laquelle les dépôts sont particulièrement bien placés pour répondre : qui la construit réellement ?

Reportz y répond, en continu, à partir de la trace que le travail laisse derrière lui.

Ce qu’il fait

Reportz synchronise un ensemble de dépôts depuis l’API publique de GitHub, à intervalle régulier, et en tire un tableau des contributions : organisations, projets et personnes, classés, avec un flux d’événements en direct et des cartes intégrables.

Le site énonce sa propre règle sur sa page méthode :

Chaque chiffre de ce site provient de l’API publique de GitHub et peut y être vérifié.

Cette phrase est le produit. Tout le reste en découle, à condition de la prendre au sérieux.

Ce qu’il compte, et ce qu’il refuse de compter

Le score est volontairement terne : pull requests fusionnées ×10, revues ×5, commits ×1, issues ouvertes ×0,5.

La page méthode de Reportz, « How the numbers are made. ». Le score y est écrit comme une formule — pull requests fusionnées ×10, revues ×5, commits ×1, issues ouvertes ×0,5 — au-dessus de l’échelle à dix barreaux et du score exigé par chacun, de signal au-dessus de 0 à kernel à 800.

Quatre décisions méritent d’être sorties du lot, parce que chacune est un refus :

Uniquement les pull requests fusionnées. Une PR ouverte n’est pas du travail livré. Elle le deviendra peut-être ; elle ne l’est pas encore.

Une revue vaut la moitié d’une PR fusionnée. La page méthode le dit mieux qu’un résumé : « Une revue en vaut la moitié, parce que c’est par la revue que le travail entre. » La pondérer à 5 — au-dessus d’un commit, en dessous d’une fusion — est une prise de position : lire le code des autres est une contribution.

Les bots sont exclus à trois niveaux. Dependabot qui incrémente un numéro de version n’est pas un contributeur, quel que soit le nombre de commits qu’il pose.

L’employeur n’est jamais déduit d’une adresse e-mail de commit. L’attribution aux organisations vient d’un fichier tenu à la main, avec pour repli le champ company du profil GitHub. C’est celle qui compte le plus : une adresse personnelle ne veut pas dire « indépendant », et une adresse d’entreprise ne veut pas dire « sur son temps de travail ». Deviner produit un graphique qui se trompe avec assurance sur la vie des gens.

Il y a aussi une échelle à dix barreaux — signal, patch, commit, branch, merge, pipeline, builder, maintainer, core, kernel — calculée sur un score glissant de 30 jours, pour mesurer ce que quelqu’un fait en ce moment plutôt que ce qu’il a fait autrefois.

D’où il vient

Reportz est un fork de Gnolove, le traqueur de contributions que nous avions construit pour l’écosystème Gno.land. Sa page méthode le dit sans détour : « Ces pondérations ont remplacé celles héritées de Gnolove, le projet dont ce site est issu, où un seul commit pesait plus lourd que cinq pull requests fusionnées ».

Ce qui est intéressant dans cette filiation, c’est que presque rien n’a eu besoin de changer. Un outil qui mesure qui construit un protocole décentralisé se trouve être le même que celui qui mesure qui construit la suite open source d’un État, parce que la question de fond est identique : d’où vient réellement le travail, et la réponse correspond-elle au récit ? Seule la liste des dépôts a bougé.

Pourquoi une coopérative construit cela

Notre Lab de recherche sur la gouvernance étudie la façon dont les collectifs se gouvernent — coopératives, DAO, projets open source — et un thème revient sans cesse : une gouvernance sans mesure est une histoire que les gens se racontent sur eux-mêmes.

On ne peut pas faire fonctionner une gouvernance pondérée par la contribution si personne ne sait dire ce qu’était une contribution. Le Proof of Contribution de Gno.land est une réponse à cela au niveau du protocole. Reportz en est une bien plus petite au niveau social : publier les comptes, publier la méthode, et laisser chacun vérifier les deux.

Le pied de page du site le dit plus simplement : « Ce projet expérimental explore le concept de gouvernance fondée sur la preuve de travail et de contribution. »

Ce qu’il ne prétend pas

Trois limites, énoncées parce qu’un outil de mesure qui cache ses bords est pire que pas d’outil du tout.

Il mesure de l’activité GitHub, pas de la valeur. Un correctif d’une ligne qui débloque quarante personnes vaut 10. Un refactoring de mille lignes vaut 10. Personne ne devrait lire l’échelle comme un classement d’utilité, et les pondérations existent pour être discutées — c’est pourquoi elles sont publiées plutôt qu’enfouies.

La liste des dépôts est un choix. Treize dépôts, nommés dans un fichier de configuration, sur les quarante-neuf que publie l’organisation. Changez la liste et vous changez tous les chiffres. C’est inévitable dans toute mesure délimitée ; la parade est de le dire.

Le dépôt n’est pas encore ouvert. La page méthode l’admet, à propos de la liste des organisations : « La liste vit dans un fichier du dépôt, qui n’est pas encore public ». Pour un projet dont tout l’argument est la vérifiabilité, c’est le manque évident, et c’est le prochain à combler.

Essayez-le

reportz.dev est en ligne en français et en anglais. Les tableaux sont publics, les cartes intégrables fonctionnent dans un README, et les comptes se remontent jusqu’à l’API GitHub. Ce qu’on ne peut pas reproduire de l’extérieur, c’est ce que contient le dépôt privé : quels treize dépôts sont synchronisés, la table d’attribution des organisations, et la liste d’exclusion, dont la page méthode dit qu’elle « n’est jamais publiée ». C’est le manque nommé plus haut.

Si vous pilotez un programme open source — administration, fondation, coopérative — et que vous voulez savoir qui le construit vraiment, la méthode est plus transportable que l’instance. Prenez les pondérations, discutez-les, publiez les vôtres.