J’attaque en donnant toutes les pistes auquelles j’ai pensé, ça sera fait
Nom: Nom international évidemment pour intéresser le maximum de monde, suggestion: FOSS Contributions
Page d’accueil avec la liste des dernières “demandes d’aide” et une explication du but de ce site
Chaque demande est affichée avec le nom du projet/logiciel qui demande (demande faite par un contributeur au projet, quel qu’il soit)
Chaque demande est dans une catégorie UX, UI, Dev feature, Translation , Issue fixing, documentation …
Une demande par catégorie: pas de demande qui en regroupe plusieurs, un contributeur ne doit pas se sentir enseveli de tâches à accomplir mais pouvoir prendre une petite tâche après l’autre s’il veut
Une demande = une durée de contribution estimée: Rapide, moyen, long. Affichée par un picto (lecture rapide)
Utilisation de tags pour les demandes afin de pouvoir filtrer dans une recherche par ex: “J’ai 10 min et je peux faire de la trad EN -> FR” ou “J’ai 2h à tuer et je peux jeter un œil au code d’un projet de messagerie communautaire parce que ça m’intéresse”
Filtre par projet également pour voir tout ce qu’un même projet a comme besoins auquels je peux répondre
Une solution par token ? pour que les contributeurs d’un projet puissent venir éditer/compléter la demande, voire la clore une fois effectuée sans avoir à partager un login/mot de passe
Chaque demande affiche aussi une courte présentation du projet (fiche projet avec date de création, language(s), captures d’écran/images/logos
Abonnement RSS à une catégorie/un projet
Voilà tout ce à quoi j’ai pensé au fil du temps, je vous laisse compléter et corriger
la plateforme doit être basée sur une API, comme ça les devs de projets pourraient facilement faire des intégrations sympa sur leur site pour encourager la contribution.
notion de savoir-faire : chaque utilisateur renseigne dans son profil ce qu’il sait faire : traduction anglais, UI, UX, dev (préciser langage), etc.
le site devrait regrouper des petits guides un peu générique sur les tâches courantes qu’on retrouve dans la contribution : faire une traduction avec weblate, créer une merge-request avec gitlab, github, etc. ces guides sont associés à des compétences.
quand une demande est faite, le mainteneur du projet renseigne une compétence (pour faire ceci, du doit savoir comment faire cela) ;
les utilisateurs renseignent au fur et à mesure leurs compétences sur leur profil (ou bien elles sont ajoutées automatiquement quand ils résolvent une tâche qui en requiert une) ;
les projets sur lequel un utilisateur s’est déjà investi apparaissent aussi sur son profil, ça permet de savoir rapidement si telle mission va lui demander un temps d’adaptation ou pas.
quand un contributeur se connecte, on lui propose des missions en fonction de ses savoir-faire et compétences et des projets auxquels il a contribué (tu sais faire ça ? Tu peux faire ça !) ;
on peut aussi ajouter un peu de gamification où on gagne des badges ou des trucs du genre, enfin moi j’aime bien ce genre de trucs mais c’est pas obligé.
Dans ce que je vois de certaines de tes propositions, tu proposes un compte pour l’utilisateur (ou plutôt appelons le nouveau contributeur/trice) j’avais éliminé cette possibilité pour des raisons de simplicité:
Pas de nouveau compte à créer encore à un nouvel endroit (frein à la création, même moi parfois j’ai pas envie parce qu’il faut encore créer un nouveau compte (OpenID n’étant plus, il me semble))
Pas de gestion des comptes robots/spam
Pas de stockage de quelques données personnelles (mail + mot de passe)
Moins de dév, plus de simplicité de la plateforme !
En gros le futur contributeur est en lecture seule sur le site
Àmha, c’est aux équipes projets de venir gérer leurs demandes sur la plateforme, quitte à donner l’auth au nouveau contributeur si justement ils ont besoin d’un “contributions manager”
Orienter un contributeur sur de nouvelles missions est une bonne idée en soi mais cela risque d’être saoulant je pense.
En revanche je verrais bien des propositions autour de ce qui aura été recherché par le visiteur/futur contributeur, qu’il y ait ou pas des résultats ça peut le motiver à aider d’autres projets s’il en avait filtré un (résultats bien distincts, un peu comme sur un site de réservation de billet de train avec des propositions pas très éloignées de dates)
Hello, j’avais commencé des vues, je partage tout ça ici (cliquez sur l’image pour zoomer).
C’est complètement à construire, mais ça m’avait permis de mettre en forme dans ma tête.
En gros il y a des projets, qui créent des tâches
Et des utilisateurs qui administrent des projets et/ou réalisent des tâches
Chaque projet libre, l’équipe comme le petit développeur dans son coin, installe un bout de l’appli. Il peut y publier ses demandes dans toute la fédération d’un coup (ou pas, blacklisting à prévoir)
Chaque site de projet libre peut donc afficher ses demandes grâce à une API, automatiser leur création … etc. (ton idée @ropoussiere ).
Chaque contributeur, armé de son compte de la fédération peut prendre en charge toute demande et la mener à terme (ou pas)
Un site commun, à la manière de joinmastodon.org et des équivalents pour les autres applis ActivityPub aggrège ces demandes et les conributions pour leur donner de la visibilité, un classement, des trophées (dont on parle ci-dessus) etc.
Un contributeur peut aussi avoir son instance pour afficher ses stats et son “CV du Libre” s’il ne veut pas dépendre d’une instance d’un projet précis
Avec une API et de l’Atom on a même pas besoin d’interface web à développer sur les instances (mais ça peut être proposé en option) les données iront directement sur les sites respectifs et l’agrégateur/nœud
Comme ça on ne recentralise pas ce genre d’organisation autour des contributions, c’était un point qui me gênait beaucoup dans l’idée de départ, il n’y a que l’agrégateur qui est centralisé mais pas indispensable non plus.
L’un des premiers soucis avec les outils actuels (aka github/gitlab) c’est que ce n’est pas convivial / inaccessible à la majorité.
Du coup avoir des tâches en Activitypub pourquoi pas, mais l’interface web me semble absolument primordiale.
Tout à fait, ça serait le rôle du noeud central de la fournir puisqu’il pourra interroger toutes les instances fédérées.
Elle pourrait être fournie en option désactivable pour ceux qui pourront s’en passer en ayant un plugin dans leurs outils pour créer les demandes
Du coup si “noeud central” il y a, ce n’est pas du total décentralisé.
On peut aussi faire un mix :
Un site central, avec une API bien fichue (c’est effectivement important).
Cette API pourrait être basée sur Activitypub, mais ça devient plus un choix de techno qu’autre chose.
C’est ce que je pensais: le site central ne serait là que pour agréger les demandes, en utilisant tous les sites fédérés et l’API (je ne sais pas techniquement comment c’est faisable). Il y aurait un point central mais non critique
Oui ce que je voulais dire c’était que chaque instance devait être interrogée par ce site central (d’ailleurs rien n’interdirai d’en avoir plusieurs) pour avoir les infos, ou à l’inverse que les instances envoient les infos à ce(s) site(s). Je ne connais pas assez ActivityPub pour savoir ce qui est préférable et optimal
ActivityPub permet à chaque instance d’interroger d’autres instances. L’idée serait donc, potentiellement d’aller sur une instance (ou l’on est inscrit et tout) mais pouvoir voir toutes les annonces/objet que tu veux du réseau d’instances…
salut !
vous avez réussi à avancer sur ce super projet ?
vous allez le faire sous activity pub ou avec gitlab ? (vous n’aviez pas parlé de git, je sais … mais vous n’y aviez peut être pas pensé )