Conception d'un outil de centralisation des informations des CHATONS

Bertille · Avril 16, 2020, 10:43

Bonjour à tou⋅te⋅s,

Nous sommes Bertille et @Adrien_L deux étudiant⋅e⋅s de l’UTC, et nous approchons le collectif des CHATONS afin de réaliser une Tx.
L’UTC, c’est l’Université de Technologie de Compiègne, une (comme son nom l’indique) école d’ingé située à Compiègne, dans l’Oise. Vous la connaissez peut-être comme la maison-mère de Picasoft.
Une Tx, c’est un projet encadré par un⋅e responsable appartenant à l’école, et qui bénéficie (potentiellement) à des commanditaires, ici les CHATONS.

Notre projet viserait à créer un modèle de ce que sont et font les différents CHATONS, afin de :

faciliter la maintenance de ces informations pour que toute la communauté soit (le plus souvent) à jour, et ce à un moindre effort,
engager la réflexion sur les aspects pratiques de la décentralisation de ces données,
proposer un outil de recherche dans cette base de données, afin de permettre à un⋅e utilisateurice (même non-averti⋅e) de trouver quel CHATONS convient le mieux à ses critères, que ce soit en terme de services, de structure, etc…

Ce projet de Tx n’a pas vocation à imposer un format aux CHATONS, simplement à proposer une des multiples approches possibles. Ainsi, ce format est amené à évoluer, et à se faire approprier ou pas par les CHATONS.

Pour l’instant, ce que nous avons à proposer serait un schéma qui validerait des fichiers JSON de description des CHATONS. Chaque membre du collectif mettrait sa description à la racine de son site, et un outil viendrait régulièrement vérifier les mises à jour de ce fichier pour les intégrer à la BDD centrale. Ce procédé éviterait d’avoir à venir mettre à jour sa fiche sur le site du collectif.

En l’état actuel, nous n’avons que ce schéma. Il reprend les critères qui existent déjà sur l’outil de recherche (https://chatons.org/find), que nous avons essayé de structurer plus. Le schéma et sa doc sont ici : https://framagit.org/bertille/tx-collecte-chatons/-/tree/master/

Dans le futur, plusieurs pistes pour enrichir les fichiers JSON se dessinent :

La première serait d’élargir le périmètre des informations à inclure dans cette fiche. On pourrait par exemple inclure dans cette fiche des indications sur où trouver de la documentation pour les différents services proposés, quels accompagnements sont proposés aux utilisateur·ices des services, s’il y a des critères (géographique ou autres) pour s’inscrire auprès du Chaton, le respect des différents items de la charte…
La deuxième serait de définir les champs du schéma en JSON-LD pour rendre les données des CHATONS plus facilement interopérables, dans l’éventualité où un collectif similaire se monterait dans un autre pays par exemple.

Est-ce que ces pistes vous paraissent intéressantes ? Et, sans aller jusque là, est-ce que certain·e·s parmi vous sont intéressé·e·s par la démarche (malgré la rude période) et voudraient bien essayer de créer la fiche de leur CHATON ? Ou même juste nous faire quelques commentaires, tous les retours sont les bienvenus.

Merci beaucoup de nous avoir lus jusque là et une bonne journée à tou·te·s,

TTDM · Avril 16, 2020, 1:46

Bonjour,

J’ai évoqué à peu près le même sujet il y a une quinzaine de jours et un membre des chatons a répondu. Vous trouverez donc des infos sur le sujet sur le thread en question :
https://forum.chatons.org/t/amelioration-de-la-page-trouver-un-chaton/971/4

Il y a notamment le lien vers Entraide.chatons.org qui correspond à un outil de recherche qui vient d’être développé et qui est plus centré sur les besoins utilisateurs que sur le détail des chatons comme peut l’être la page trouver un chaton. Il y a aussi le lien vers des fichiers JSON qui décrivent déjà les chatons

Il est cependant toujours possible d’améliorer ce qui a été fait :

Je pense effectivement qu’il est possible d’améliorer les JSON pour les rendre plus complet, comme vous le proposez, par contre il faudrait, à mon avis, travailler avec les membres du collectif pour fixer le JSON avant de demander de les remplir (vous ne demandez par exemple pas le soft utilisé pour chaque service ce qui me semble personnellement être une info utile (peut être à tord, peut être à raison, je pense que les mieux placer pour en décider sont les chatons)).
De son coté, entraide chatons vient d’être créé donc il reste nécessairement du travail (ne serait ce que pour y inclure les services qui n’y sont pas encore (entre autre tout ce qui concerne l’hébergement longue durée)).

Il y a en tout cas une solide base existante. Votre projet devrait donc prendre en compte ce qui existe

Edit : sur la partie JSON après avoir lu la totalité du repo git

ljf · Avril 16, 2020, 1:56

Bienvenue à vous 2,

La problématique à laquelle vous proposer de participer a déjà fait l’objet de plusieurs discussions. Pour ma part, sur l’aspect technique, j’en retiens 2 approches :

Une approche décentralisée à base de JSON, sur le modèle de ce que vous proposez. L’approche a d’ailleurs été retenue par le collectif LibreHoster https://libreho.st/ qui est similaire à CHATONS mais qui vise à s’étendre au delà de la francophonie
Une approche plus centralisée au travers de la base de données actuelle sous Drupal

A savoir également la Fédération FDN a mis en place un système similaire avec des JSON chez chaque FAI cf: https://db.ffdn.org/ . A noter également que les FAI ont le choix entre héberger le json OU remplir une fiche sur db.ffdn.org. Donc on voit qu’il y a eu une tentative de conciliation des 2 approches.

Il y a 2 ou 3 discussions sur ce forum à propos de cette thématique. Je retiens pour ma part une argumentation de pyg : https://forum.chatons.org/t/covid19-mise-en-place-dentraide-chatons-org/901/8?u=ljf

Mais l’argument de la décentralisation est intéressant aussi, d’autant que librehoster ou la ffdn ont déjà des parties d’outils.

J’estime pour ma part qu’avoir accès à une description des services permettra à la fois de créer des outils de recherche efficaces mais aussi de pouvoir tester automatiquement la disponibilité des services.

Sur l’aspect du modèle de donnée, il y a effectivement pas mal de travail à faire je pense. ET d’ailleurs on a probablement été un très vite avec le lancement de entraide.chatons.org, donc ce qu’on a actuellement devrait être amélioré.

Ce soir il y a une réunion en ligne, n’hésitez pas à passer dire coucou et présenter le cadre de votre TX.

djayroma · Avril 17, 2020, 3:13

Sur les deux approches :

Le fait d’avoir des ressources décentralisés, ne t’empêche pas d’avoir un base centralisé… Tu vas forcément parser tes ressources pour les fixer dans un base que tes outils vont exploiter.

Donc si on a une base, on peut tout à fait la « remplir » de manière « manuelle », ou via un formulaire comme ça semble être le cas pour FDN…

Du coup je vois pas en quoi c’est incompatible… Autant avoir un outil qui permet les deux.

ljf · Avril 17, 2020, 4:24

Le trucs comme le dit @pyg c’est qu’en cas de mise à jour du format il faut s’assurer que tout le monde met à jour son json ou gérer la retrocompat, donc maintenir le bouzin comme le dit très exactement pyg.

Et dans les faits, pour participer au FFDN Camp depuis 3 ans, il y a chaque année quelqu’un qui doit se coller à la mise à jour de l’outil.

D’un autre côté, grace à ce système et depuis que COIN fonctionne avec le json de la FFDN j’ai jamais besoin d’aller mettre à jour les infos dans db.ffdn.org, ça se fait tout seul.

djayroma · Avril 17, 2020, 6:45

Bon ben j’ai commis ça
https://framagit.org/jeromeavond/entraide_gen

En suite il suffit que chacun indique une URL avec ses services mis en forme comme ça :
https://framagit.org/chatons/entraide/-/blob/master/src/data/chatons-services.json

Et du coup, la moulinette va récupérer et générer un gros fichier json…

Rien d’automatique, une bonne vieille crontab fera le job à date.

++

djayroma · Avril 18, 2020, 7:45

Je viens d’ajouter un autre projet, pour faciliter la création des fiches de services en json
https://framagit.org/jeromeavond/chatons_gen
Là c’est pas du tout abouti car j’ai quelques problèmes

Il y a une parti « répétitive » sur chaque service (nom du chaton, url du chatons, description etc…), j’aimerais en simplifier la saisie ‹ une bonne fois pour toute ›
Je ne trouve pas une liste des programmes (« software »), y a bien ça : https://framagit.org/chatons/entraide/-/blob/master/src/data/softwares.js mais je sais pas si c’est exaustif…
Il faudrait je pense définir les paramètres une bonne fois pour toutes, j’ai l’impression qu’il y en a des requis et d’autres optionnels.
Je cherche une bonne « interface » pour faciliter la vie à chaque chaton, tout le monde n’a pas forcément le goût pour remplir un fichier json
Je penche pour le Yaml, plus simple à remplir, l’export en json est simple comme bonjour,

Bertille · Avril 21, 2020, 2:45

Merci pour vos éléments, @TTDM, @ljf et @djayroma !

C’est super ce qui a été fait avec entraide.chatons.org ! Comme tu le fais remarquer @TTDM ça ne permet pas (encore) de trouver un chaton pour des services qui s’inscrivent plus dans la durée et ça répond à des usages différents que la recherche d’un chaton en tant que structure, mais le travail de référencement des différents services est top. Et oui, les réflexions qui ont été menées à cette occasion sur la simplicité de mise à jour des fiches et la nécessité de ne pas dupliquer les données sont précieuses. On compte bien s’appuyer sur cette base pour faire quelque chose d’aussi pertinent que possible

En effet, ce que font LibreHoster et la FFDN est intéressant, on ira sans doute piocher des idées là-bas [Même si leur code est vachement moins clair que ton crawler @djayroma) Et la meilleure solution est sans doute de garder les deux options et gardant bien en tête que le schéma risque d’être chamboulé à l’avenir pour ne pas s’arracher les cheveux à chaque mise à jour.

Pour le modèle de données, merci aussi pour vos retours ! On va intégrer le soft du service, et puis toutes autres choses que vous pourriez trouver utiles.

Enfin, merci aussi (ça fait beaucoup de mercis :D) pour le coup de pouce sur la génération de JSON, pour Entraide, on va voir s’il faut adapter/ce qu’on peut faire. Même si effectivement, le problème de la répétitivité qui se pose pour Entraide n’existe pas pour la recherche plus générale de Chaton

djayroma · Avril 21, 2020, 8:11

Salut,

Et ben MERCI pour le retour ça fait super plaisir de ~~voir~~ lire qu’on a pas bossé pour rien

Des bisous

Adrien_L · Mai 7, 2020, 2:17

Bonjour à tou⋅te⋅s,

Avec @Bertille nous avons fini une première version du système de crawler et d’agrégation des jsons dans un fichier accessible en ligne \o/
Tout le code est disponible sur le framagit : https://framagit.org/bertille/tx-collecte-chatons

Le schéma

Propose une description complète de ce que sont les Chatons et leurs services.
Les fichiers valides selon ce schéma pourront servir à alimenter entraide.chatons.org/

Le crawler

Lit en entrée un fichier listant les urls des différents jsons décrivant les Chatons
Agrège les informations, selon diverses options comme la validation par rapport à un schéma ou la vérification de l’unicité du chaton.
Sort un fichier json contenant ces données, disponible sur le site : http://chatons.picasoft.net/exports/chatons.json

Toutes les informations sont détaillées sur le readme approprié du framagit

Le site

Est disponible sur : http://chatons.picasoft.net/
Documente notre projet, nos choix et le fonctionnement des outils
Propose un fichier json mis à jour chaque nuit en fonction des urls trouvés et parsés sur le repo
Proposera bientôt un outil de recherche utilisant ce json à titre de preuve de concept

Si vous avez la moindre question ou des retours à nous faire, n’hésitez-pas ! En attendant, merci de nous avoir lu et bonne journée à vous !

unteem · Mai 8, 2020, 12:10

Trop bien, ca a l’air top ! Je vais regarder tout ça plus en détails

Petite question vous avez envisagé de traduire ce json en json-ld ? En se basant par exemple sur schema.org et/ou d’autres. C’était le projet à la base avec LibreHosters mais personne ne s’en ait jamais trop occupé

numahell · Mai 8, 2020, 1:58

Hello,

Alors tout d’abord, bravo pour le taf. Comme c’est du python, que c’est mon langage de prédilection, et que c’est un projet étudiant, je peux vous faire des retours ? j’ouvre une issue sur le git si vous voulez pour ne pas polluer ici.

Après sur l’usage, j’ai des doutes sur la mise à jour régulière et manuelle d’un fichier json aussi long par chacun des 70 membres du collectif, chaque chaton ayant des compétences et une disponibilité disparates (en leur sein et entre eux), je ne suis la bonne approche. Peut-être qu’un formulaire aidant à la saisie permettrait de simplifier la tâche (comme dans les fiches sur le site actuellement), mais c’est du taf en plus.

Vu que pour le moment je n’ai pas l’impression qu’il y ait de consensus dans le collectif si on doit utiliser les infos sur le site drupal ou les centraliser ailleurs et autrement, il est difficile de savoir si votre travail sera utilisé.
Dites-vous que vous faites un POC (proof of concept), et ne vous formalisez pas si vous vous rendez compte qu’au final c’est abandonné, ça arrive plusieurs fois dans une carrière de développeur (ça m’est déjà arrivé).

djayroma · Mai 8, 2020, 8:08

@Bertille Bravo, beau boulot

@numahell c’est le problème, il faut créer un formulaire qui permette de tenir à jour facilement le json de son chaton.
Pour y avoir réfléchit un peu, ça me parait relativement compliqué :

D’abord il faut « fixer » les champs nécessaires (ce qui semble avoir été fait dans le projet de @Bertille)
Ensuite il y a certains champs ou il faut fixer les valeurs (type de programmes, durée, etc)
Ce « générateur de json » sera où ? Chaque chaton dispose du sien propre ? Un générateur unique permet de créer les fichiers ?
- Mine de rien c’est un sujet important pour prendre en charge les « évolutions » du json
Est-ce que tout les chatons vont comprendre le principe d’un fichier hébergé en web qui est crawlé par une instance unique pour approvisionner entraide ? à priori oui, sinon le présence au sein des chatons est à remettre en cause (il faut un minimum de compréhension technique il me semble, sans devoir être expert, car sinon c’est la porte ouverte à l’incompétence qui peut mener à l’insécurité et à la malveillance)
Est-ce que tout le monde « jouera le jeu » ? En tenant à jour son fichier (la moindre de tâche ICC (interface chaise clavier) est à monitorer en détail) ? Il va falloir ajouter une adresse mail et un service de monitoring pour éviter la sédimentation de liens « en l’air ».

Bref c’est mes réflexions que je vous soumet, vous pouvez les balayer d’un revers de main parce que je comprend rien à rien, peu me chaud

Je vous embrasse

djayroma · Mai 8, 2020, 8:28

Après avoir vu le schéma (http://chatons.picasoft.net/schema.json)

  "properties": {
    "url": {
      "description": "Site web du CHATONS",
      "$ref": "#/definitions/url"
    },
    "name": {
      "description": "Nom du CHATONS",
      "type": "string"
    },
    "description": {
      "description": "Description courte du CHATONS",
      "type": "string"
    },
    "servers": {
      "description": "Listes des hebergeurs du CHATONS",
      "type":"array",
      "items": { "$ref": "#/definitions/url" },
      "uniqueItems": true,
      "minItems": 1
    },

Je le trouve BEAUCOUP trop complexe, quel est le besoin de mettre des "type": "string" qui alourdissent alors que bon une chaîne de caractère c’est quand même simple de la détecter…
Il y a des redites partout description: description: type string … C’est pénible à lire, et ça doit être l’enfer à éditer…

KEEP IT SIMPLE :

Je propose un YAML beaucoup plus simple :

Chaton:
  url : String
  name : String
  description : String
  creation_date : String
  address : String
  perimeter : String
  structure : String
  status : String
  public : [String]
  economic_model : [String]

Services:
  - name: String
    type : String
    url : String
    software : String
    account : String
    price : String
    degradability : Public
  - name: String 
    (...)

Ne pas se répété, faire simple : un service = 7 lignes et c’est tout

Cordialement,

djayroma · Mai 8, 2020, 9:05

Bon j’avais pas lu le bon fichier : Je vous prie d’accepter mes excuses …

http://chatons.picasoft.net/exports/chatons.json

Ok c’est plus simple, mais finalement le format YAML me parait plus simple à maintenir à la main.

En conséquence je viens de faire 2 Merge Request :

Une parce que le code n’était pas bon dans crawler.py : https://framagit.org/bertille/tx-collecte-chatons/-/merge_requests/1
Une pour ajouter la possibilité de parser des fichiers YAML (selon moi plus simple à éditer qu’un JSON) : https://framagit.org/bertille/tx-collecte-chatons/-/merge_requests/2

Voilà voilà,

++

Adrien_L · Mai 12, 2020, 10:27

Bonjour tout le monde !
Déjà, merci grandement pour vos retours.

@unteem Petite question vous avez envisagé de traduire ce json en json-ld ?

Complètement ! C’était un des enjeux du projets, mais nous ne sommes pas focalisés dessus pour le moment, nous voulions d’abord produire quelque chose de fonctionnel en json « simple ». Et devant la difficulté de savoir comment utiliser des termes existants (sur schema.org ou d’autres instances signifiantes) ou en créer de nouveaux qui permettent de définir les Chatons, nous pensions vous poser deux-trois questions avant de commencer à travailler en ld.

@djayroma

D’abord il faut “fixer” les champs nécessaires

C’est ça ! C’est ce qui a été fait dans le schéma proposé.

Ce “générateur de json” sera où ? Chaque chaton dispose du sien propre ? Un générateur unique permet de créer les fichiers ?

C’est la question compliquée de cette Tx, on peut imaginer que celui-ci est généré à partir du formulaire d’inscription, mais il n’est pas évident de partir du principe que chaque Chaton explicite tous ses services et leurs détails lors de l’inscription, et cela pose effectivement des problèmes de mise à jour. On pourra imaginer une interface s’occupant spécifiquement de cette génération pour les Chatons les moins techniques. Qui sait ?

Est-ce que tout les chatons vont comprendre le principe d’un fichier hébergé en web qui est crawlé par une instance unique pour approvisionner entraide ?

Ce qu’il faut comprendre c’est que c’est de la responsabilité de chaque Chaton d’expliciter ses activités (stockées donc dans un fichier dont il faut communiquer l’adresse au groupe), s’il veut être trouvable par l’outil de service central.

Est-ce que tout le monde “jouera le jeu” ?

Dans tous les cas cette question se pose : Qui maintient à jour la base de recherche, qui décide de ce qui est valide ? On imagine que ce fichier, s’il sert à permettre de trouver un chaton (essentiellement par ses services) ne change pas non plus souvent, et que dans tous les cas il faut bien qu’un Chaton informe le collectif d’un changement s’il veut que ce changement soit pris en compte.

Pour le Yaml, nous étions parti.e.s sur du Json avec un schema, mais rien ne nous empêche a priori d’utiliser du Yaml avec schema si c’est plus lisible.

@numahell Merci énormément pour ton issue, effectivement on va s’occuper de ça en priorité, à savoir utiliser des modules standards plutôt que des maisons, et découper et clarifier le code.
Dans tous les cas, nous sommes bien conscient.e.s que nous faisons une expérience qui échouera peut-être, mais si elle permet d’invalider une technologie ou un mode opératoire, bref d’avancer un peu sur la question, ce sera déjà ça.

Merci encore pour vos retours, à très vite !

neil · Mai 13, 2020, 10:53

Hello !

Tout d’abord, bravo pour votre super idée, que je trouve très pertinente dans ce contexte.

Petit retour sur votre format (et désolé si je répète une proposition déjà donnée, je n’ai pas lu l’intégralité du fil).

Ça pourrait être une page sur chatons.org. Ça semble faisable avec une page html unique, entièrement statique, avec possibilité d’importer un json existant et de le modifier, puis de l’exporter. (je suppose qu’il faudrait faire ça en Javascript…)
Ensuite n’importe qui pourrait autohéberger la page html sur leur propre serveur si besoin.

D’où l’idée d’avoir un générateur qui nous évite d’avoir à maintenir un document à la main. Avis perso, mais supporter des formats différents dans ce cas d’usage risque de compliquer la tâche plus qu’autre chose… Parce que le crawler va devoir envoyer plusieurs requêtes sur chaque CHATONS (ex.: s’il ne trouve pas 42l.fr/services.json, il devra chercher 42l.fr/services.yaml).

Ça serait comme avoir un robots.txt, robots.md et un robots.odt qui donnent tous la même information. Dans ce cas d’usage, il me semble important d’avoir un même format standard, interopérable et normé.

En parlant de standards, vous n’avez pas défini de règle quant au chemin du fichier en question sur chaque plateforme CHATONS. Il me semble pertinent de faire usage du dossier well-known dans ce cas. Exemple : framasoft.org/.well-known/services.json. L’idéal serait de faire en sorte que tout le monde utilise le même chemin, ça faciliterait les choses

En parlant d’interopérabilité, le fichier s’oriente plutôt vers les CHATONS (et c’est génial !) mais ce standard pourrait s’appliquer au-delà du collectif : pour d’autres collectifs également, et même pour tout hébergeur de service sur Internet. C’est peut-être voir trop grand et/ou trop demander, mais ça serait génial si vous moduliez 2-3 champs de votre format de façon à ce qu’il ne s’applique pas seulement aux CHATONS

En parlant de norme, les champs sont en anglais et les valeurs sont en français. Quitte à voir grand, vous pourriez concevoir votre format pour qu’il puisse être utilisé à l’international ! (mais surtout, choisissez entre anglais et français, pas les deux en même temps )

Champs potentiellement manquants

Champs généraux

Il pourrait être pertinent d’ajouter un champ « version » (int) pour que derrière, le parseur traite différemment les champs en fonction de la version (si vous ajoutez des champs, etc.)
Un champ « logo » facultatif (qui soit un lien vers une image distante) serait plutôt sympathique, mais cela impliquerait que le crawler télécharge l’image en local pour éviter une requête de tierce partie côté client. À méditer ? Par ailleurs, vous avez également (à priori) le logo de chaque structure sur chatons.org.

Champs par service

pouvoir spécifier une date de fin de service si le service est temporaire. C’est utile pour les services qui sont seulement mis à disposition en temps de confinement, ou lorsqu’un CHATONS souhaite fermer ses services petit à petit (Framasoft par exemple )
Comme pour entraide.chatons.org, pouvoir spécifier une pondération entre 1 et 10, valeur 5 par défaut, pour un usage avec un round-robin en frontend. De façon à ce que si on sent que notre service commence à être surchargé, qu’on puisse mettre une pondération de 1 pour diminuer la fréquence de suggestion du service dans le frontend.
Pour le champ price, je ne suis pas certain de ce que nous devons mettre. Dans le json que vous avez rédigé pour nous, vous avez mis « gratuit » pour nos services à accès restreint (réservé à nos adhérent·e·s). Mais l’adhésion à notre association est payante. Les services en question devraient-ils donc être marqués comme payants également ?
Deux champs software et source_code pourraient être intéressants dans ce contexte (je crois que c’est un peu comme ça que fonctionne pour entraide.chatons.org).
Un champ description pour le service n’est jamais de trop
Le champ degradability n’est pas très modulaire et ne s’applique qu’à certains services. Peut-être remplacer sa valeur par un int correspondant au nombre de jours ? Sinon, peut-être le mettre dans un champ plus générique metadata (objet) qui listerait tous les champs spécifiant des paramètres propres au logiciel / service hébergé (ex: stockage autorisé pour une instance PeerTube, liste des applications Nextcloud proposées, liste des noms de domaines proposés par un service mail…). Le frontend n’aurait plus qu’à piocher dedans.

Catégorisation des services

Vous souhaitez catégoriser les services par type, ce qui semble tout à fait adapté dans ce contexte. Mais c’est très compliqué de standardiser tout ça. Les catégories actuelles sur le site CHATONS ne sont pas assez précises, notamment si le but derrière c’est de faire du round-robin sur des instances de logiciels très catégorisés. Quelques exemples, pouvez-vous catégoriser et différencier :

Une instance Invidious ? Nitter ?
Un résolveur DNS ? DoT ? DoH ?
Un client de messagerie instantanée (Riot/Matrix) d’un serveur de messagerie instantanée (Synapse/Matrix) ?

La question, c’est de savoir jusqu’où granulariser la catégorisation des services tout en gardant un format assez lisible, bien qu’il vaut mieux partir du principe que le fichier sera créé avec le générateur, mais éventuellement remplissable à la main par des personnes qui savent ce qu’elles font.
Enfin, il faut qu’il soit facile d’ajouter / proposer de nouvelles catégories sans casser les catégories existantes.

Bon voilà, je le redis, mais j’aime beaucoup votre idée. Votre outil répond à un réel besoin au sein du collectif. Angie et Lise vous seront certainement reconnaissantes pour ne plus avoir à contacter chaque CHATONS afin de recenser toutes les instances de chaque logiciel sur entraide.chatons.org

Continuez comme ça, vous faites du super taff

~ Neil

ljf · Mai 14, 2020, 9:48

Pour ma part je suis un peu moins optimiste. On déplace le problème: là où il faut aujourd’hui remplir un formulaire sur le site chatons.org, il faudra héberger un fichier et penser à le modifier. C’est quasi sûr qu’il faudra faire des relances pour que ces fichiers soient à jours ou simplement présents (en tout cas c’est comme ça au sein de la FFDN).

ljf · Mai 14, 2020, 9:50

Dans ce cas je propose, que le fichier soit forcément un yaml, car le format yaml contient la norme json.

djayroma · Mai 14, 2020, 11:39

Je te rassures, ça sera la même chose avec un formulaire, une base de donnée, un fichier tableur, un message par pigeon voyageur, un post-it…

L’avantage (je trouve), c’est que c’est comme le DNS : tu gères ta partie, si tu la gère mal tant pis pour toi et un peu tant pis pour nous, mais au moins si t’es motivé tu n’as pas à attendre qu’un mec du centrale s’occupe de toi dans la pile gigantesque du TODO qu’il a sur son bureau.

C’est pas fou, mais au moins on délègue, c’est la base du truc CHATONS non ?

++