Comment la santé est calculée

Upstar classe les dépôts selon la vitesse à laquelle ils gagnent des étoiles. Les signaux de santé posent une seconde question, distincte : le projet est-il activement maintenu ? Ils aident à distinguer un projet en hausse et entretenu d’un emballement passager. Ils sont factuels, calculés automatiquement à partir de données publiques, et ne constituent jamais une garantie.

Niveaux

En bonne santé : un score de santé de 70 ou plus.
Signaux mitigés : de 40 à 69.
Peu d’activité : moins de 40.
Trop récent pour juger : dépôts de moins de 60 jours, ou avec moins de 10 commits. Les dépôts en hausse sont souvent récents ; un historique court ne les pénalise pas.
Archivé : le propriétaire a archivé le dépôt sur GitHub. Il est toujours signalé, quel que soit son score.

Composantes et pondérations

Le score va de 0 à 100. Chaque composante donne une valeur de 0 à 1, multipliée par sa pondération. Quand une composante ne peut pas être mesurée, elle est écartée et les autres pondérations sont augmentées d’autant : une donnée manquante ne compte jamais comme mauvaise.

Régularité de l’activité (30 %) : le nombre de semaines, parmi les 13 dernières, avec au moins un commit d’une personne sur la branche principale. Les commits automatiques sont écartés : comptes finissant par [bot] (Dependabot, Renovate…), commits créés ou validés par GitHub Actions, bots de synchronisation qui utilisent des comptes ordinaires (comme celui de gVisor), identités git sans compte GitHub dont le nom ou l’e-mail contient bot, robot, automation, copybara ou sync, et commits écrits par une application via le flux web de GitHub. Des commits sur 10 semaines ou plus donnent la valeur maximale.
Mainteneurs et facteur bus (20 %) : combien de personnes (automatisation écartée, comme ci-dessus) ont commité parmi les 100 derniers commits des 90 derniers jours (une personne 0,4, deux 0,7, trois ou plus 1), et quelle part du travail repose sur la plus active (50 % ou moins : travail bien réparti, 100 % : pas du tout). Avec moins de 20 commits sur la période, cette composante est réduite en proportion : une poignée de commits en dit peu sur qui maintient un projet.
Réactivité sur les issues (20 %) : le délai médian avant qu’un mainteneur (le propriétaire, un membre de l’organisation ou un collaborateur) commente pour la première fois une issue ouverte par quelqu’un d’autre au cours des 90 derniers jours, sur un échantillon des 50 dernières issues. Les commentaires de bots ne comptent jamais, quel que soit leur rôle : GitHub Actions, Dependabot, Renovate, bots « stale » et tout compte finissant par [bot]. Les issues encore en attente comptent avec leur âge actuel ; celles fermées sans commentaire d’un mainteneur (par leur auteur ou un bot « stale ») sont écartées. Un jour ou moins donne la valeur maximale, 30 jours ou plus aucune. Un quart de cette composante correspond à la part de ces issues qui sont fermées. Avec moins de 3 issues de ce type, elle est inconnue.
Rythme des versions (10 %) : versions GitHub publiées au cours des 12 derniers mois (une 0,5, deux ou trois 0,75, quatre ou plus 1). Les projets qui ne publient jamais de versions GitHub ne sont pas jugés là-dessus.
Hygiène du projet (20 %) : une licence (35 %), de l’intégration continue (35 % : des workflows GitHub Actions ou une autre configuration de CI), une politique de sécurité (15 %) et, quand le projet a été analysé, son score OpenSSF Scorecard (15 %).

Affiché aussi, sans compter dans le score

Pull requests ouvertes, fusionnées et fermées au cours des 90 derniers jours (les 50 dernières).
Le score OpenSSF Scorecard, avec un lien vers le rapport complet. Un projet jamais analysé est inconnu, pas mauvais.

Limites

Les signaux sont relevés une fois par semaine pour les dépôts classés dans au moins un thème : ils peuvent dater de quelques jours. La date du dernier relevé figure sur la page de chaque dépôt.
Les décomptes viennent d’échantillons (les 100 derniers commits, 50 issues, 50 pull requests et 50 versions). Quand un échantillon est plein, le nombre réel peut être plus élevé.
La protection des branches n’est pas visible avec un accès public : elle ne fait donc pas partie du score.
Le travail hors de GitHub (autres forges, listes de diffusion, discussions privées) est invisible ici.
Un projet en bonne santé peut tout de même avoir des bugs ou des failles, et un projet calme peut être terminé et stable. Lisez le code et la documentation du projet avant d’en dépendre.