Comment les chiffres sont établis.

Le score d’une personne est la somme pondérée de ce qu’elle a livré dans la fenêtre que vous consultez. Une pull request fusionnée est l’unité de travail. Une revue en vaut la moitié, parce que c’est par la revue que le travail entre. Un commit compte, mais un commit à lui seul n’est pas une contribution.

score = pull requests fusionnées × 10
      + revues                   × 5
      + commits                  × 1
      + issues ouvertes          × 0,5

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 et où une personne à trois pull requests pouvait devancer une personne à dix-sept.

Le statut d’une personne se lit sur son score à 30 jours : dix paliers, nommés d’après la façon dont le travail traverse un dépôt. C’est un état mouvant, pas une médaille : il décrit les trente derniers jours et change avec eux. Une fenêtre vide n’affiche aucun statut. Les dix noms restent en anglais : ce sont les mots du travail lui-même, et ceux que portent les badges et les images de partage.

01  signal      score > 0
02  patch       score ≥ 10
03  commit      score ≥ 30
04  branch      score ≥ 60
05  merge       score ≥ 100
06  pipeline    score ≥ 160
07  builder     score ≥ 250
08  maintainer  score ≥ 380
09  core        score ≥ 550
10  kernel      score ≥ 800

Les seuils sont des constantes du dépôt et ne changent que par pull request, la même règle que les pondérations ci-dessus, parce qu’un rang que des personnes portent mérite des règles publiées.

Seules les pull requests fusionnées comptent : une pull request ouverte n’est pas du travail livré. Les bots sont exclus de la paternité des pull requests. Treize dépôts de l’organisation suitenumerique sont synchronisés ; la liste se trouve dans server/config/ecosystem-config.yaml et change par pull request.

Les bots sont exclus partout : les auteurs de pull requests et de revues, d’après le type que GitHub leur attribue, les commits des GitHub Apps dès l’ingestion, et les comptes machines qui ressemblent à des comptes ordinaires, listés dans server/config/bots.yaml, une courte liste publiée qui change par pull request.

Une personne est rattachée à une organisation de deux façons : une liste tenue à la main dans server/config/organizations.yaml, ou le champ « company » de son profil GitHub public. Les entrées tenues à la main l’emportent sur le champ du profil.

Les adresses e-mail des commits ne sont jamais utilisées pour déduire un employeur. Cela fonctionnerait, et ce serait une trahison envers quiconque a déjà poussé du code depuis un ordinateur professionnel.

Pour revendiquer une organisation, corriger une attribution ou ajouter un membre, écrivez-nous à hello@samourai.coop. La liste vit dans un fichier du dépôt, qui n’est pas encore public : nous faisons donc la modification nous-mêmes et vous prévenons une fois en ligne.

Si vous préférez ne pas figurer ici, écrivez à hello@samourai.coop en demandant à en être retiré. Aucune justification demandée, aucune question de suivi. Vous ajouter à la liste est le travail d’une personne : comptez un jour ou deux. Ensuite c’est automatique et définitif — chaque synchronisation consulte la liste et supprime à nouveau vos commits, pull requests, issues, revues et rattachements, si bien que rien ne peut vous y remettre discrètement. La liste elle-même n’est jamais publiée.

Les avatars et les logos d’organisation passent par le proxy d’images de ce site : votre navigateur ne parle jamais à GitHub ni à aucun tiers quand quelqu’un consulte un tableau ou une intégration. Quand aucune image n’existe, un monogramme est généré localement à partir du nom.