La db de la FFDN (lien dans mon premier message), le code est ici code.ffdn.org/ffdn/ffdn-db
L’idée est de voir si il est possible de se baser dessus pour un usage similaire pour le Collectif Chatons.
Il n’y a pas encore de données dispo sur les sites des Chatons (a ce que je sais) mais on peut assez facilement en mettre en place. (je peut le faire très facilement sur le site en cours de dev de mon Chaton)
Merci pour ta réponse ! entre temps j’ai édité mon message.
Une autre solution serait effectivement de forker simplement le code de la ffdn et de le mettre en place sur les chatons !
C’est à peu prêt comme ça que fonctionne le système de la FFDN.
Je suis utilisateur//co-fondateur de Touraine Data Network qui à son json ici https://www.tdn-fai.net/isp.json.
Il y as un validateur qui permet de valider une première fois le fichier et lancer le premier pull des info par le serveur central.
Ensuite c’est fait de façon cyclique toutes les 24h environs, avec je me doute (j’espère ? ^^) un décalage pour par faire les x requêtes au même moment)
Si jamais le pull rate trop (plus de x fois ?) un mail est envoyé à l’adresse d’admin du FAI avec une demande de revalider le json via le validateur pour relancer les pull réguliers.
Je les ai ping sur le salon IRC #ffdn (serveur Geeknode).
Alors, si je suis les échanges sur ce post, il semblerait que vous soyez plusieurs à souhaiter participer à ce groupe de travail. Afin de pouvoir en discuter lors d’une première réunion en septembre, je vous invite à compléter ce framadate : https://framadate.org/DrzmYYGojfIDwrSw
J’ai répondu !
Au regard des réponses inscrites dans le Framadate, la première réunion du groupe de travail stats.chatons.org aura lieu le jeudi 10 septembre à 20h.
J’ai créé un pad où je vous invite à compléter l’ordre du jour et/ou commencer la réflexion :
https://mypads.framapad.org/p/gt-stats-chatons-org-8h6ly7dn
La première réunion du groupe de travail a eu lieu jeudi dernier. Nous étions 3 : @Cpm, @mrflos et moi-même.
@Cpm nous a montré son outil/protocole StatoolInfos qu’il est en train de mettre au point pour Chapril. Nous avons décidé d’adapter ce modèle pour y faire apparaître les champs qui nous semblent importants et nous proposerons ensuite au collectif d’utiliser ce système pour mettre en commun des informations sur leur structure (dont un certain nombre de données statistiques). Cet outil peut tout à fait être utilisable pour d’autres activités d’un chaton et il est possible d’automatiser la récupération des données.
stats.chatons.org sera un site web complet présentant toutes les données récoltées mais il sera aussi possible d’afficher certaines données (dans un but de valorisation de l’activité des structures du collectif) sur chatons.org et entraide.chatons.org
La première étape de ce travail est donc de penser les champs qui vont composer les différentes sections à compléter par les structures qui le souhaitent. Pour cela, nous avons publié la liste des champs dans un projet sur le groupe Git du collectif. Et nous avons prévu 2 temps pour étayer, modifier, améliorer cette liste :
Vous êtes bien sûr les bienvenu⋅es sur ces temps de travail. Et si vous n’êtes pas disponibles, vous pouvez toujours consulter la liste actuelle des champs et nous transmettre ce que vous aimeriez y voir apparaître ou toutes autres réflexions sur sa composition.
Bonjour,
Ca semble très intéressant, mais je ne vois pas trop le résultat attendu.
Cet outils est un genre de référentiels des infos de chaque CHATONS si je comprends bien ?
Ta compréhension est plutôt bonne oui. En favorisant un partage d’information « normalisé » sur les chatons et leurs services, les résultats attendus sont :
L’idée est de faire ça de façon simple et légère : 1 fichier par chaton, 1 fichier par service. Dont la maintenance sera facile pour les chatons volontaires. Ces fichiers seront collectés régulièrement et serviront à générer des pages web statiques de valorisation.
Cette approche n’exclut pas d’autres solutions/approches qui seraient possibles. Là, on expérimente une voie qui a tout sa pertinence par rapport à nos contraintes et disponibilités 
Salut qu’est-ce qui a motivé votre choix de ne pas capitaliser sur le travail qui a été fait par les étudiants ? https://framagit.org/bertille/tx-collecte-chatons
Leur approche ouvrait tout un champs des possibles avec la possibilité de porter leur schéma sur du json-ld.
Je comprends l’intérêt du fichier properties pour les metrics mais pour le reste je trouvais leur solution plutôt sexy. D’ailleurs je me pose des questions sur l’intérêt de balancer des metrics comme ça, en tout cas chez IndieHosters je ne vois pas trop comment on va pouvoir participer, on ne va pas s’amuser à balancer publiquement les stats d’utilisations de nos contributeurs, on veut bien être transparent mais quand même
(bon je te dis ca, j’étais pas là donc bon…)
J’ai pas suivi non plus, mais au final, s’agit-il de proposer une api standardisée? Auquel cas, un truc comme https://swagger.io/ pourrait faciliter la validation du modèle?
Ce qui a motivé le choix, c’est tout simplement que @cpm a proposé cette solution et que personne d’autre n’a proposé de revenir sur le travail des étudiants. @mrflos et moi-même (les seul⋅es autres personnes présent⋅es à cette réunion) avons trouvé que cette solution tenait la route et qu’elle était vraiment simple à mettre en œuvre. Car même des personnes sans compétences techniques pourront facilement compléter ces fichiers properties.
Alors quand on parle de modèle, c’est effectivement un bon réflexe que de penser à des outils d’écriture, de validation, schéma… Mais bon, dans notre cas, il y a seulement une vingtaine de champs descriptifs très simples. Donc ça ne vaut pas vraiment le coup de s’alourdir avec des procédures contraignantes. Dans un premier temps, démarche de faire simple, le plus simple possible
Exemple avec le fichier décrivant un membre (version non finalisée) : https://framagit.org/chatons/chatonsinfos/-/blob/master/MODELES/membre.properties
De nombreux aspects du projet de Bertille et Alain sont très intéressants et j’invite tout le monde à revoir la vidéo de leur excellente soutenance : https://forum.chatons.org/t/conception-dun-outil-de-centralisation-des-informations-des-chatons/1074/50
Plusieurs points sont repris, d’autres le seront et ça doit rester une référence intéressante à consulter. Comme l’indique avec raison @Angie, la tentative de se passer de json-ld est liée l’opportunité d’abaisser significativement la complexité des outils et des tâches humaines. Donc une plus grande chance de réussite par rapport au temps et ressources disponibles.
Ce ne sont pas les données de vos contributeurs qui sont visées. Ce sont celles de votre chaton.
Exemples :
De part leur nature consolidée et globalisée, ces données sont donc anonymes. Par contre, elles permettront de se rendre compte de l’activité des services. Tel service est-il très demandé ? Très utilisé ? Demande-t-il beaucoup de ressources ? De quoi alimenter les sections transparence et solidarité du manifeste du collectif CHATONS.
Dans la page https://indiehosters.net/, on peut lire « 9571 personnes de 46 organisations bénéficient de nos solutions. » Voilà, 9571 utilisateurs est un métrique intéressants qui ne dévoile rien de sensible ou de personnel.
À noter que la liste des métriques reste à définir ensemble au sein du collectif.
Simplement en fournissant quelques fichiers properties décrivant votre chaton et ses services, lorsque la première version sera validée. Ensuite, en y ajoutant itérativement des métriques acceptables par votre équipe. Cette mise à disposition est volontaire, sans obligation et peut être progressive.
Merci d’avoir été ouvert et de continuer à avoir cet élan pro-actif 