Currency-Monit : Monitoring d'une monnaie et de sa toile de confiance

Présentation

Currency-Monit est un module Duniter permettant de faire du monitoring de la monnaie, de la toile de confiance et des données en piscine, vous pouvez en découvrir les fonctionnalités sur les instances publiques :

Réseau Ğ1 :
https://g1-monit.elois.org/
https://duniter.help-web-low.fr/monit/
https://g1.cgeek.fr/modules/currency-monit/

Réseau ğ1-test :
http://g1-test-monit.monnaielibreoccitanie.org

Currency-Monit compte actuellement 6 pages*, d’autres pourront se rajoutées au gré de mes envies de développement ou/et des besoins de la communauté Duniter :slight_smile:
*A noter que l’une des pages est une intégration d’un autre module : wotex

Vous pouvez également installer votre propre instance currency-monit sur votre nœud duniter comme n’importe quel autre module duniter.

Compatibilité

Duniter version 1.3.9 ou supérieure.

Impressions d’écran

Installation

Pour installer ce module il vous suffit de récupérer l’url du tar.gz de la dernière version sur le dépot github :

Puis de copier-coller cette url en bas de la page modules de votre web-ui (= interface web de duniter desktop).
Vous pouvez aussi installer ce module en ligne de commande avec la commande :

duniter plug url_du_fichier_tar.gz

Configuration

Si vous lancez duniter sans web-ui (duniter server), vous devrez utiliser la commande suivante pour lancer votre nœud :

duniter currency-monit [host] [port]

Attention cela lancera votre nœud en mode direct_start, si vous souhaitez qu’il continue à fonctionner après fermeture du terminal, vous devez utiliser un outils de détachement de processus comme screen par exemple (il y en a d’autres).

Sans web-ui, le module currency-monit utilise son propre serveur web qui écoute par défaut sur localhost:10500 (les options [host] et [port] vous permettent de lancer le serveur web sur l’hôte et le port de votre choix :slight_smile: )

Avec la web-ui, le module currency-monit utilisera le serveur web de la web-ui et sera accessible en rajoutant /modules/currency-monit après l’url de votre web-ui.

6 Likes

Nouvelle version 0.2.11

  • Harmonisation de la gestion des identités multiples entre willMembers et wotex !

Vous pouvez constater dés a présent le fonctionnement sur g1-monit avec l’utilisateur maximec par exemple :slight_smile:
ou encore avec Olipez et lascapi

On voit sur cette capture d’écran que le lien wotex proposé pour maximec est maximec[1], vous trouverez bien plus bas un autre maximec avec zéro certifications dont le lien wotex est cette fois-ci maximec[0] :

2 Likes

J’ai pour projet de créer le fameux détecteur de l’état de tension de la toile comme le besoin en a déjà été exprimé par @florck et d’autres !

Cela fais plusieurs jours que j’y réfléchi intensément et je suis arrivé a la conclusion que la façon la plus optimale de procéder est d’utiliser la valeur DistanceResult.nbSuccess calculée par le module wotb a chaque fois que la règle de distance est vérifiée. Cette variable contient le nombre de membres référents depuis lesquels il existe au moins un chemin qui respecte la règle de distance.

Connaissant le nombre total de membres référents, la différence entre ces deux nombres me permettra de savoir quel est le nombre de référents bloquant pour chaque nouvel entrant (ainsi que pour chaque membre devant se renouveler).
Ce qui est exactement l’indicateur dont j’ai besoin pour mesurer l’état de tension de la toile, même si la façon d’interpréter cette valeur pour définir une échelle de l’état de tension de la toile reste à déterminée.

Seulement, il y a un problème, cette fameuse variable DistanceResult.nbSuccess est bien calculée par le module wotb, mais à la lecture du code il n’a apparemment pas été prévu de moyen de récupérer sa valeur, c’est dommage :cry:
je viens donc d’ouvrir une issue ici : https://github.com/duniter/wotb/issues/10

3 Likes

Je peux effectivement rajouter une fonction qui te renverrai le nbSuccess, nbSentries, isOutdistanced. Mais il te manquerait encore une info utile à mon avis : nbReached.

Car nbSuccess mesure le nombre de référents atteints. Tu pourrais vouloir connaître tous les membres atteints, référents ou pas, comme donnée supplémentaire.

Je vais développer cela tout de suite.

1 Like

Voilà, wotb@0.6.x publié.

Tu ne vas pas pouvoir l’utiliser depuis le serveur Duniter par contre, ce dernier utilisant wotb@0.5.x qui ne contient donc pas la nouvelle fonction.

Il te faudra ajouter wotb en tant que module Node.js avec un :

yarn add wotb

(ou avec npm plutôt que yarn, c’est pareil)

Pour l’utiliser, c’est très simple :

const wotb = require('wotb')

// Alimenter wotb avec la toile Ğ1
const wotbInstance = wotb.newFileInstance(duniterServer.home + '/wotb.bin')

// Préparation des paramètres
const node = 34 // Un membre
const d_min = Math.ceil(Math.pow(5, 1 / wotbInstance.getWoTSize()) // Niveau pour être référent
const k_max = 5 // Distance max
const x_percent = 0.8 // Paramètre x_percent

// La nouvelle fonction développée
const distance = wotbInstance.detailedDistance(node, d_min, k_max, x_percent)
console.log(distance.nbReached)
console.log(distance.nbSuccess)
console.log(distance.nbSentries)
console.log(distance.isOutdistanced)

A noter qu’il ne faut pas être surpris si distance.nbSentries varie de 1 parfois. En réalité sa valeur pendant le calcul de distance dépend de l’observateur : si celui-ci n’est pas un référent, alors il voit tous les référents, mais s’il l’est lui-même, alors la distance ne le compte pas parmis les référents.

C’est un détail pas forcément très important, mais il peut jouer à la marge.

1 Like

Wow quelle rapidité merci beaucoup !!

J’ai regarder un peu le commit et bien que je comprenne parfaitement le C++ j’aurais été incapable d’ajouter cette fonction moi-même, c’est surtout la partie binding que je ne comprend pas bien, j’ai l’impression que ça te force à déclarer ta fonction à 10 endroits a la fois, et en plus tu est obliger de remettre en forme chaque résultat pour qu’il soit correctement lu par nodejs, bref c’est chaud quoi :astonished:

Merci je l’avais déjà remarqué a la lecture de la fonction computeDistance :slight_smile:

Ha c’était donc pour ça le petit commit en plus que je ne comprenais pas. Merci beaucoup !

Bon ben maintenant j’ai du pai :sur la planche :blush:

Bon j’ai deux problèmes.

lorsque je teste dans un environnement de dev, et que j’éxécute la page willMembers j’ai ça :

TypeError: binding.detailedDistance is not a function
    at Object.detailedDistance (/home/duniter/duniter-currency-monit-dev/node_modules/wotb/index.js:126:20)
    at /home/duniter/duniter-currency-monit-dev/routes/willMembers.js:293:36
    at next (native)
    at onFulfilled (/home/duniter/duniter-currency-monit-dev/node_modules/co/index.js:65:19)

J’ai publier mon code de dev ici, peut-être que je ne m’y prend pas comme il faut : https://github.com/duniter/duniter-currency-monit/blob/dev-module/routes/willMembers.js#L285-L293

Deuxième problème, si j’essaye de pluger le module, sur un nœud duniter local, alors là ça refuse carrément de compiler :

$ duniter plug file:///home/duniter/duniter-currency-monit-dev/
Trying to install module “file:///home/duniter/duniter-currency-monit-dev/”…
true true

> wotb@0.6.2 install /opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb
> node-pre-gyp install --fallback-to-build

gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR
gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/6.11.0"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/.node-gyp"
gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR
gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR
make: Entering directory '/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/build'
make: Leaving directory '/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/build'
make: *** No rule to make target '../.node-gyp/6.11.0/include/node/common.gypi', needed by 'Makefile'. Arrêt.
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/opt/duniter/node/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Linux 3.14.32-xxxx-grs-ipv6-64
gyp ERR! command "/opt/duniter/node/bin/node" "/opt/duniter/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--fallback-to-build" "--module=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64/wotb.node" "--module_name=wotb" "--module_path=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64"
gyp ERR! cwd /opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb
gyp ERR! node -v v6.11.0
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok 
node-pre-gyp ERR! build error 
node-pre-gyp ERR! stack Error: Failed to execute '/opt/duniter/node/bin/node /opt/duniter/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64/wotb.node --module_name=wotb --module_path=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:106:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:891:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
node-pre-gyp ERR! System Linux 3.14.32-xxxx-grs-ipv6-64
node-pre-gyp ERR! command "/opt/duniter/node/bin/node" "/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd /opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb
node-pre-gyp ERR! node -v v6.11.0
node-pre-gyp ERR! node-pre-gyp -v v0.6.23
node-pre-gyp ERR! not ok 
Failed to execute '/opt/duniter/node/bin/node /opt/duniter/node/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64/wotb.node --module_name=wotb --module_path=/opt/duniter/node_modules/duniter-currency-monit/node_modules/wotb/lib/binding/Release/node-v48-linux-x64' (1)
Error during installation of the plugin: could not retrieve or install the plugin

Tu devrais relire mon message précédent avec plus d’attention, je te vois toujours utiliser wotb@0.5.x, qui bien sûr ne contient pas la fonction detailedDistance().

Puis concernant l’installation en tant que module, à mon avis ça risque de ne pas fonctionner pour l’instant. Tu ne pourras publier une nouvelle version de currency-monit si tu as wotb en dépendence directe, car peu de gens pourront l’installer (cela requiert des outils de compilation, etc). Tu ne pourrras publier cette nouvelle mouture que quand wotb@0.6.x sera fourni par Duniter.

Je ne sais pas si je suis clair, tu comprends pourquoi ?

non ça c’est parce que j’ai commenté le nouveau code et réactivé l’ancien pour publier une mise à jours mais j’utilisais bien la version 0.6.2 :confused:

Ha oui tu veut dire que la commande plug n’est pas capable de compilée a la volée des dépendances C++, ok ça se comprend en même temps se serait plus compliqué. Ok j’attendrais donc, mais j’aurais bien aimer pouvoir au moins coder en dev d’ou ma remarque d’au dessus. Tout ceci ne répond donc pas a ma 1ère question !

Si, dans mon message initial je te donne l’exemple :

const wotb = require('wotb')
const wotbInstance = wotb.newFileInstance(duniterServer.home + '/wotb.bin')

Il faut bien que tu utilises cette autre instance, et ne pas prendre celle membre de l’objet duniterServer.

Pas besoin de te répéter j’avais bien compris cela dés le départ et c’est bien ce que j’ai fait et ça ne fonctionne pas, mais merci quand même :slight_smile:

EDIT: comme je te sent suspicieux je viens de créer une autre branche pour t’y partager le code que j’ai tester : https://github.com/duniter/duniter-currency-monit/blob/dev-wotb6/routes/willMembers.js#L285-L307

C’est le code que j’avais déjà tester a mon antépénultième message et j’ai toujours le même message d’erreur publié au dessus :

TypeError: binding.detailedDistance is not a function
    at Object.detailedDistance (/home/duniter/duniter-currency-monit-dev/node_modules/wotb/index.js:126:20)
    at /home/duniter/duniter-currency-monit-dev/routes/willMembers.js:293:36
    at next (native)
    at onFulfilled (/home/duniter/duniter-currency-monit-dev/node_modules/co/index.js:65:19)

J’avais du mal à imaginer le code qui te provoquait le bug, du coup j’ai pris le PC puis cloné la branche dev-module et fait un git reset --hard HEAD^ pour retomber sur le commit [enh] fix #4 où il me semble que tu rencontrais le bug.

Depuis tu as créé la branche dev-wotb6, mais je faisais déjà mes essais avant donc je n’ai pas vérifié celle-ci.

Sauf que je ne tombe pas sur ton erreur, le code s’exécute correctement, il n’y d’erreur nulle part. Tu fais l’appel correctement, et le module contient bien la méthode detailedDistance().

Je pense qu’il n’y avait aucun soucis de code depuis le début, par contre yarn ou npm a dû s’emmeler les pinceaux, te forçant à utiliser la version 0.5.x de wotb alors que tu as expressément demandé la 0.6.x.

Je pense cela car au début en clonant la branche dev-module, je me suis retrouvé avec des modules de duniter@1.4.x, encore en développement …

Je te conseille de supprimer totalement le dossier node_modules, puis de relancer yarn ou npm.

1 Like

Merci c’est cette phrase qui m’a donner l’idée que mon problème ne venait peut être ni de mon code ni de wotb mais de mon environnement.
Du coup j’ai recloner mon dépôt sur un autre répertoire donc en recompilant tout comme il faut et ça a fonctionner :grinning:

Oui je crois aussi que c’est exactement cela, j’ai encore peu d’expérience avec ces outils et donc je n’aurais jamais imaginé en premier ressort qu’ils puissent êtres responsables de mon problème :innocent:

Du coup ça fonctionne parfaitement, en capture d’écran les données [nbSuccess/nbSentries] (nbReached :

1 Like

Je t’avoue que comme j’avais testé le bon fonctionnement de wotb 0.6.x sur currency-monit avant d’annoncer cela ici, je me disais que le problème venait forcément du code que tu utilisais.

Bien mal m’en pris, le problème était encore ailleurs !

Et niveau perfs, tu trouves cela comment ?

Sinon, Duniter 1.4 ne sortira pas avant fin Juillet à mon avis, donc il y aura un peu d’attente pour bénéficier de cette mise à jour. Mais peut-être que tu comptes déployer cette fonction sur ton nœud g1-monit.elois.org ?

1 Like

En fait ce qui m’a froissé c’est le fait de croire que je t’avais mal lu, il peut m’arriver de mal comprendre, mais je lis toujours en entier tes explications avant de te déranger ! Et d’ailleurs je te remercie encore pour le temps que tu passe à m’aider et pour les nouvelles fonctionnalités de wotb :slight_smile:

Pour l’instant je ne ressent aucune différence dans le temps d’exécution de willMembers, c’est donc de très bonnes perf comme je m’y attendais :slight_smile:

Cela demanderai que je lance mon nœud g1-monit en mode dev via run.js, oui je pense que je n’attendrais pas fin juillet pour le faire :slight_smile:

2 Likes

Currency-Monit version 0.3 déployé sur https://g1-monit.elois.org et http://g1-test-monit.elois.org !

Cette nouvelle version ne pourra hélas être packagée en module que pour duniter 1.4.x car elle utilise une version plus récente de wotb qui n’est pas intégrée a duniter 1.3.x … ceux qui le souhaite peuvent toutefois l’installée en mode dev depuis le dépot.

EDIT : suite à un bug j’ai créer une version correctrice 0.3.1 par contre avec toutes ces manip la piscine de g1-monit s’est vidée donc la page willMembers est vide, soyez patient, elle redeviendra complète d’ici demain.

EDIT 2 :page willMembers rétablie ouf ! Cette page restait vide suite a une regression de la version 0.3.1, il m’a donc fallu déployer un correctif 0.3.2 :stuck_out_tongue:

Il y a beaucoup de nouvelles informations concernant l’état de la toile de confiance sur les pages willMembers et members :slight_smile:

Mon objectif est d’afficher des indicateurs nous permettant de jauger finement l’état de tension de la toile.
Il y a notamment 2 indicateurs globaux qui m’ont sembler pertinent pour évaluer l’état global de la toile :

  • la proportion de couples orientés pour lesquels il existe un chemin de 5 pas ou moins : 59.66%
  • la qualité moyenne : actuellement 1.06

Explications:

Qualité d’un membre

Ce que je nomme qualité d’un membre (je pourrais changer le terme si vous m’en proposez un plus pertinent) c’est le rapport entre le taux de membres référents rendu atteignables par une certification de ce membre et le taux de membres référents qui faut atteindre pour respecter la règle de distance.
Je vais donner un exemple pour que ce soit plus clair :
prenons une toile avec 10 membres référents et xpercent=0.8. Et bien la qualité d’un membre dans une telle toile c’est le rapport entre le nombre de membres référents qu’il permet de joindre en moins de 5 pas et 8. Donc si un membre bob permet de joindre 4 référents il aura une qualité de 0.5.
Et si bob permet de joindre les 10 référents il aura une qualité de 10/8=1.25.

Qu’entend-je par “permet de joindre”, quand je dit que Bob permet de joindre x membres référents j’entend que si Bob certifie une nouvelle identité (qui n’est certifiée que par Bob) alors il y aura x membres référents pour lequels il existera un chemin de moins de 5 pas de eux vers la nouvelle indentité.

Ainsi, un membre ayant une qualité supérieure un égale à 1, pourrait faire rentrer un nouveau a lui seul sil la règle sigQty n’existait pas.

Lorsque la qualité moyenne est supérieure à 1 c’est que la règle de distance n’est pas contraignante, lorsque la qualité moyenne s’approche de 1, la règle de distance va devenir contraignantes pour quelques cas minoritaires, et lorsque la qualité moyenne devient inférieure à 1, alors la règle de distance devient contraignante pour la majorité des identités (par identités j’entend nouveaux+membres souhaitant ce renouveller!)

Actuellement la qualité moyenne est de 1.06, ce qui signifie que la règle de distance n’est pas contraignante, donc la toile n’est pas “trop” tendue, mais 1.06 c’est proche de 1, donc si tout les membres ne certifient que vers l’extérieur a partir de maintenant alors la règle de distance pourrais redevenir contraignante rapidement (ce qui peut être une situation souhaitable et voulue dans certains cas, c’est aussi une liberté des membres que de tendre ou détendre la toile).

Degré de centralité

Il y a aussi un second critère qui me semble pertinent, cette fois ci inspiré de la théorie des graphes, c’est la centralité d’intermédiarité, que je nomme juste centralité pour faire simple, visible sur la page membres :

Le degré de centralité d’un membre (au sens de l’intermédiarité), c’est le nombre de fois qu’il apparaît sur le plus court chemin entre deux membres. Ce nombre mesure vraiment le degré de contribution d’un membre a la densité de la toile.
Vous pouvez classer les membres par centralité dans currency-monit : https://g1-monit.elois.org/members?lg=fr&d=400&sort_by=centrality&order=desc

Le degré de centralité moyen n’a de sens que comparativement à la taille de la toile, vous devez donc le comparer au nombre de couples de membres (N^2-N). Par exemple au 4 juillet 2017 dans la toile Ğ1 la centralité moyenne est de 395.45 et le nombre de couples de membres est 31506 donc cela signifie qu’un membre fait en moyenne le lien entre 1,25% des couples de membres. Mais même ce nombre n’a pas de sens car plus la toile grandira plus un membre représentera une part relative de membres faible.

Donc plutôt que de considérer le degré de centralité moyen, il me semble plus pertinent de considérer la proportion de couples orientés pour lesquels il existe un chemin satisfaisant la règle de distance (donc de 5 pas ou moins).
Pourquoi orientés ? parce que les couples (Bob->Alice) et (Alice->Bob) sont différents, les chemins sont unidirectionnels dans une toile duniter, donc dire qu’un chemin existe de Bob vers Alice ne signifie pas nécessairement qu’il existe un chemin d’Alice vers Bob !
Dans la toile Ğ1 du 4 juillet 2017, il existe un chemin satisfaisant la règle de distance pour 59.66% des couples orientés. On peut considérer que ce nombre est un facteur de densité, si la toile était parfaitement dense, ll existerai un chemin satisfaisant la règle de distance pour 100% des couples orientés, on peut donc considérer que la toile Ğ1 est actuellement dense à 60% :slight_smile:

9 Likes

Wow je ne sais pas si c’est l’effet rmll mais ces jours-ci ya un monde fou qui requête g1-monit via tor,
pour rappel donc g1-monit est accessible en service caché à cette adresse : http://ylckrwzkggcf4smt.onion

Bon du coup j’ai quand même les log mais je n’ai pas votre ip c’est déjà ça :stuck_out_tongue:

2 Likes

Bien vu, très bien vu même. Très bonne idée cet indicateur !

Comme tu dis, cela reste une moyenne. Donc en moyenne la règle de distance n’est pas contraignante, mais cela n’exclue pas localement qu’elle le soit, malgré une qualité moyenne > 1.

Bon après, avec la règle sigQty = 5, la contrainte de distance est passée “facilement” malgré tout, même si cela n’exclue toujours pas des cas isolés, je me rappelle d’un nouvel entrant qui restait à la porte malgré 6 certifications.

Mais bref, bonne idée :slight_smile:

Il doit y avoir un petit bug quelque part (#57), car Alfybe apparaît en multiples doublons à la fin de la liste.

Mis à part cela, le fait de voir “le pont” @kimamila en tête de liste semble cohérent avec cette définition de centralité !

Bon indicateur individuel qui signifie : une certification de ce membre ne sera pas contrainte par la règle de distance.

La moyenne est très souvent un indicateur très peu porteur d’information, aussi je suggère des pistes pour améliorer cet indicateur individuel vers un indicateur global plus pertinent :

  • Une répartition graphique de l’indicateur par membre, mais pas classé du plus haut vers le plus bas, mais en plaçant le plus haut au centre (sous forme de gaussienne). Pour ce faire : classer du plus bas au plus haut dans une table (par exemple 200 membres), et placer le premier dans la table sur le 1 du graphe, puis le second sur le 200 du graphe, le 3ème en place n°2 du graphe, le 4ème en place n°99 etc… On verra ainsi une répartition où l’indicateur le plus élevé sera au centre.
  • Un indicateur en % = (nombre de membres > 1) / nombre total de membres, plus pertinent que la moyenne
  • Un indicateur en % plus fin : (nombre de membres > 1,5) / Nb total, ( 1,5 >nombre de membres > 1) / Nb total

Les deux derniers indicateurs consistent à tracer des lignes horizontales sur le graphe, qui donne donc à lui tout seul une indication la plus fine possible de la (WoT Ğ | cet indicateur de qualité), et donc le graphe ferait tout.

4 Likes