Publié Arrow up right Modifié Arrows round Haut Arrow bar to up Status checklist Documentation folders Dépôt de code source code tag Licence license Page photo du projet camera Étiquette d'article ou de page tag Catégorie box Check checkmark Écriture en cours writing Point important Arrow right

epy is a geek.net
Informatique et bidouilles, libres

  • Statut: brouillon

Publié le
Mis à jour le

# FedeHelp

L’idée de départ

Ce brouillon de projet traîne dans ma tête depuis longtemps, totalement abandonné au moins une fois, puis de nouveau d’actualité quand des discussions sur Mastodon ont mené à la conclusion qu’il y a bien un besoin réel:

> Comment savoir où contribuer à des projets libres et quoi faire ?

> Quel projet a besoin d’aide dans un domaine où j’ai des compétences ?

Le constat est fréquent, tous les projets Libres (logiciels sous licences libres, matériel sous licences libres, ..) cherchent de la main d’œuvre; tous ne savent pas communiquer à ce sujet et les infos sont éparpillées sur les forums, les wikis, les listes de diffusion, etc. de chaque projet, quand il y en a !

Ce qui semble manquer c’est une meilleure communication des besoins: cela demande les compétences ou l’aisance et la disponibilité d’une personne pour publier régulièrement l’information à jour, une personne bien intégrée au projet pour être au courant des besoins en temps réel. Une sorte de Community Manager pour un projet non commercial.

Autre possibilité, formater la communication des besoins, comme un fichier robots.txt, facilement accessible sur tout serveur web du projet.

Inconvénients:

  • Il faut toujours aller manuellement consulter le fichier de chaque projet pour savoir de quoi ils ont le plus besoin.
  • La recherche n’est pas facile, les contributions multi-projet encore moins.

Il faut donc une plateforme unique afin de regrouper tout ces besoins.

Un crawler (robot scannant les sites web) pourrait aller consulter chacun de ces fichiers et mettre à jour ses informations à afficher publiquement. Mais cela demanderait des ressources techniques très importantes ou une déclaration préalable de chaque site web de la disponibilité d’un tel fichier.

Regrouper cela n’est pas facile, re-centraliser ces infos sur un site vitrine va à l’encontre de la décentralisation générale menée par les acteurs libristes de tous les pays (notemment Framasoft).

Cette discussion a fait évoluer ma réflexion vers une plateforme décentralisée avec un point central non critique.

La centralisation des informations, dans ce cas précis, ne serait pas dangeureuse en cas de panne de la vitrine centrale:

  • L’utilisation de chaque instance reste possible et reste la seule méthode pour mettre à jour les besoins du projet.
  • La recherche de contributions “à combler” serait toujours possible grâce au filtre débrayable sur l’instance d’un projet afin de visualiser tous les projets.
  • Aucune information n’est perdue puisqu’elles viennent des instances publiques et ne font qu’être affichées.
  • N’importe qui peut re-créer le site vitrine, en sélectionnant le filtre par défaut pour les visiteurs, le logiciel est exactement le même.

Note

Le nom FedeHelp est temporaire, ouvert aux contributions.

Un projet similaire a démarré suite à des échanges sur Framacolibri sur Framateam et le wiki.

Les bases

Ce qui semble idéal, pour le moment, est l’utilisation d’un système fédéré comme l’utilisent les instances de Mastodon, Pleroma, Pixelfed, Plume et de nombreux autres: le protocole ActivityPub.

Chaque projet hébergerait son instance de l’application, elle pourrait communiquer avec toutes les autres mais n’afficherait par défaut que les besoins du projet en question sur une page dédiée, aux couleurs du logiciel.

Une instance centrale, sous forme de pages web donc, regrouperait également ces demandes de contribution, sans filtre par défaut afin de permettre à un visiteur de chercher très largement sans avoir à visiter les sites de chaque projet.

C’est aussi une astuce pour avoir un lieu visible, une vitrine vers laquelle diriger un·e potentiel·le contributeur·trice.

Pour éviter la gestion des comptes et des droits, les projets n’hébergeant pas leur instance de l’application ne pourraient soumettre de demande de contribution.

Note

C’est une restriction à étudier, cela simplifie nettement le code et évite la recentralisation mais risque de bloquer les tous petits projets sans serveur perso.

L’utilisation

Dans mon idée de départ, je souhaitais éviter la création d’un compte utilisateur pour qui souhaiterait contribuer, cela alourdit le processus et freine les contributions.

Un visiteur peut consulter toutes les demandes de contribution et se rendre sur le site du projet pour commencer.

Les demandes doivent contenir un niveau de compétences estimé, une durée estimée, un nombre de contributeurs nécessaires, le taux d’accomplissement, …

La notification de contribution en cours ou terminée serait inscrite par un administrateur de l’instance afin d’éviter les doublons.

L’administration de l’instance peut être partagée par tous les membres réguliers du projet, la solution technique et sécurisée pour cela reste à étudier.

L’avantage des comptes utilisateur en revanche, permettrait d’enregistrer les compétences d’un visiteur et d’enregistrer les filtres utilisés sur chaque projet Cela peut aussi permettre l’établissement d’un tableau de score avec les contributions effectuées. Le coté ludique est intéressant, mais cela ne risque-t-il pas de dériver ?

Les comptes Mastodon, Pleroma etc. sont déjà créés pour les réseaux fédérés, il serait probablement simple de les réutiliser et peut-être de poster automatiquement un message indiquant la réussite d’une contribution afin de motiver d’autres utilisateurs.

Retour en haut