Après avoir modernisé sa forge logicielle (utilisation de Gitlab depuis 2018) et sa messagerie instantanée (utilisation depuis cet été de Matrix avec un pont IRC), la communauté GNOME a annoncé qu’elle allait désactiver ses listes de discussion d’ici fin octobre en faveur de son instance Discourse.
Discourse est un forum open-source en ligne sur le web, pas forcément révolutionnaire, mais a priori plus facile d’accès qu’une liste de discussion pour les divers membres de la communauté.
Comme Andrea Veri le relate dans un billet plus détaillé, il y a eu plusieurs raisons pour décider de migrer des listes de discussion vers Discourse :
- depuis plusieurs années, le projet GNOME se focalise sur la modernisation de son infrastructure
- depuis que Discourse a été mis en place par GNOME (il y a plus de 3 ans), l’instance Mailman de GNOME a vu son utilisation décliner
- Discourse offre bien plus de modernités avec le support de Markdown, des flux RSS, une réelle gestion des spams, plusieurs types d’authentification, les prévisualisations des sujets, une interface mobile et des tonnes de plugins, le support d’API…
- réduire la fragmentation de la communauté et consolider les plateformes de discussions autour de Discourse et Matrix (avec un pont IRC)
- la modération est plus aisée et peut être portée par plus de volontaires : avec Mailman, il y avait bien quelques volontaires pour certaines listes de discussion, mais ils disparaissaient après quelque temps et finalement c’était soit à l’équipe d’infrastructure de se charger de la modération, soit des dizaines de courriels qui restent bloqués en attente de modération. Il était impossible de passer à l’échelle avec le système de modération prévu par Mailman spécialement avec une communauté composée de personnes qui participent majoritairement sur leur temps libre. Il vaut mieux que leur temps libre soit utilisé pour donner un coup de main au projet avec des outils qui doivent simplement fonctionner, avoir une bonne interface utilisateur et être assez simple à appréhender.
- il y a des dizaines de manières d’intégrer Discours avec d’autres services via les webhooks et d’autres intégrations
- la migration a été discutée et proposée il y a plus de deux ans par l’équipe GNOME Engagement et a été acceptée
Emmanuele Bassi avait aussi écrit un commentaire un peu plus tôt expliquant également que:
- techniquement il est difficile de gérer la réputation des courriels envoyés par des grands serveurs de listes de discussion puisqu’ils ressemblent très fortement aux services de spam
- la barrière technique pour les nouveaux utilisateurs était trop élevée (voir les nombreux commentaires du journal LinuxFr à ce sujet)
- l’infrastructure utilisait Mailman 2 qui est une très vieille version qui utilise Python 2 (en fin de vie également), ce qui commençait à rendre sa gestion dans l’infrastructure difficile en particulier pour sa sécurité. D’ailleurs Andrea explique à la fin de son article que, si la migration vers Discourse avait été refusée, les utilisateurs des listes de discussion auraient quand même subits une migration vers Mailman 3 ou un autre outil.
Cette modernisation des outils d’infrastructure a donc pour objectif d’augmenter les interactions entre les différents membres de la communauté : le fait d’utiliser ces outils modernes (Gitlab, Matrix, Discourse…) permet de baisser les connaissances nécessaires pour augmenter le partage.
Bien sûr, il y aura plus de bruits s’il y a plus de monde, mais il y aura également plus de partage d’idées nouvelles et de retours pertinents, ce qui sera très utile pour améliorer les logiciels et la gestion de la communauté.
Techniquement, en ce qui concerne la migration, les archives des listes de discussion resteront accessibles en ligne en lecture seulement et aucun nouveau courriel ne sera distribué à partir de la fin octobre.
Pour les utilisateurs qui préfèrent continuer à interagir par courriel, il est possible de configurer Discourse pour interagir avec des courriels. Cependant, il faut d’abord augmenter un peu sa réputation en utilisant d’abord l’interface web (ce qui permet d’éviter certains courriels de spams envoyés par des robots).
Les projets sont donc en train de se déplacer vers cette nouvelle plateforme, comme le projet GIMP ou encore orca et a11y.
Aller plus loin
- Le Discourse de GNOME (162 clics)
- Annonce de la désactivation des listes de discussion GNOME (27 clics)
- Journal à l’origine de la dépêche (133 clics)
- Discourse, plate-forme de discussion atypique (60 clics)
- Les raisons détaillés du changement (27 clics)
- Interagir avec Discourse par courriel (23 clics)
# Pas trop convaincu
Posté par mathieui (site web personnel) . Évalué à 10.
Pour cette décision en particulier, je ne sais pas (vu que je ne fréquentais pas les mailing lists de la communauté GNOME), mais de mon expérience personnelle, remplacer les mailing lists par discourse ça change complètement l’usage et la population d'utilisateurs présents.
Utiliser discourse sans javascript, c’est impossible, utiliser discourse comme une mailing list avec l'interface mail, c'est impossible (c’est techniquement possible, mais en pratique ce n'est pas tenable, car il n’y a pas de threads corrects, pas de citations au format mail, et surtout, beaucoup plus de messages entrants qui sont aussi beaucoup moins construits).
Je vois après le passage de l’espace de discussions des CHATONS vers discourse, je n'ai simplement pas l'énergie pour aller consulter un forum périodiquement (où des décisions importantes sont prises par ailleurs), et après avoir activé l'interfaçage email je l'ai vite désactivé car c’est beaucoup trop de messages, dans un format pas très agréable à lire.
Ce n'est pas pour critiquer la décision du passage à discourse dans un cas où dans l'autre (les pour et contre ont certainement été pesés, même si ça m'affecte négativement), mais c'est plus honnête de dire qu'on supprime les mailing lists et qu’on ouvre un discourse, que dire qu’on va remplacer un avec l’autre.
[^] # Re: Pas trop convaincu
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 27 octobre 2022 à 12:54.
Discourse fournit une API rest il me semble, donc si ça doit être possible:
https://docs.discourse.org/openapi.json
Je n'ai pas cherché mais il y a probablement déjà des interfaces pour terminaux.
As-tu testé l'utilisation d'un lecteur de flux rss? (en rajoutant .rss à l'url d'une catégorie tu obtiens son flux dédié).
Il n'y a pas de différence sémantique significative dans ces deux affirmations. Un remplacement n'a pas forcément les mêmes caractéristiques et fonctionnalités.
[^] # Re: Pas trop convaincu
Posté par Pinaraf . Évalué à 10.
J'adore ce genre de réponse. «y'a une api, c'est bon, tu peux coder ton client dans ton coin». Ça me fait penser à ceux qui me traitent de passéiste à vouloir garder XMPP pour qu'on continue à avoir nos clients desktops et pas des bousins en JavaScript, avec exactement le même argument de l'API.
La présence d'une API, si tant est qu'elle soit complète, n'est pas suffisant. Ne serait-ce que du point de vue du développeur d'un client : Si demain une fonctionnalité est ajoutée sur l'interface web mais absente de l'API, et qu'elle rend des éléments invisibles, comment faire ? Comment être notifié de l'arrivée de nouvelles APIs ? Et c'est pas un travail anodin, c'est long et fastidieux de faire un client pour ce genre d'usage.
Puis du point de vue d'un utilisateur qui explique qu'on lui retire son outil, «t'as qu'à t'en coder un», c'est une excellente idée ma foi…
Également, d'un point de vue philosophique, pourquoi est-ce-que je développerais un client pour un logiciel, certes libre, mais avec un protocole propriétaire à ce logiciel, et chapeauté par une entreprise dans un paradis fiscal ? Dans mon taf précédent, on subissait Slack, j'avais commencé à coder un client alternatif en Qt… Je l'ai utilisé un temps, mais j'en ai arrêté le développement, car au final rendre Slack utilisable, c'est améliorer cet outil, et c'est clairement pas à moi de le faire sur mon temps libre…
J'ai cherché, je n'en ai pas trouvé. En tout cas pas dans les paquets Archlinux, ni les paquets Debian, ni sur Internet.
D'ailleurs, ça n'a pas été listé lors de la discussion du projet Debian sur une éventuelle utilisation de Discourse, cf https://lwn.net/Articles/817668/
# Retour d'expérience
Posté par Sébastien Dinot (site web personnel) . Évalué à 6.
J'ai proposé il y a quelques années aux communautés de deux projets libres – Orekit et Orfeo Toolbox – d'abandonner les listes de diffusion au profit de Discourse. Aujourd'hui, personne ne reviendrait en arrière, y compris parmi les membres qui étaient déjà très actifs sur les listes de diffusion, car il est difficile de se passer des fonctions proposées par Discourse une fois qu'on y a goûté.
Pour Orekit, un trimestre après la bascule, le nombre d'échanges avait été multiplié par 2,5, preuve que les listes de diffusion ne convenaient pas à tout le monde, même si cela n'avait jamais été exprimé.
[^] # Re: Retour d'expérience
Posté par Pinaraf . Évalué à 3.
Tout dépend de la communauté existante et de son acceptabilité d'un tel changement.
Sur par exemple le noyau ou le projet PostgreSQL, un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail).
D'ailleurs, dans les plaintes contre la migration de GNOME sur discourse, j'en ai vu une assez intéressante : il s'agissait des développeurs d'evolution… Et effectivement, c'est «amusant» de voir qu'on retire aux développeurs d'un logiciel un outil de communication qu'ils utilisaient avec leur logiciel.
[^] # Re: Retour d'expérience
Posté par Sébastien Dinot (site web personnel) . Évalué à 7.
Bien sûr qu'il appartient aux communautés de choisir les outils qui leur conviennent le mieux. Dans les exemples cités, j'ai proposé l'outil, en développant mon argumentaire, et les contributeurs ont accepté cette migration. Ce que je souligne, c'est que même si certains étaient tièdes ou sans avis à l'époque, je suis sincèrement convaincu qu'ils ne reviendraient plus en arrière aujourd'hui quand je vois à quel point ils se sont appropriés le nouvel outil.
Pour ma part, les listes de diffusion ne me dérangent pas, mais je suis un vieux (une preuve parmi d'autres : le client mail que j'utilise à titre privé est Mutt !) et je sais qu'elles ne conviennent pas à tout le monde, notamment à cause du fait qu'une fois abonné, on reçoit tout le trafic dans sa boite mail et que même lorsqu'un mode « digest » est proposé, la réception quotidienne d'un mail dérange certaines personnes, qui se sentent débordées (véridique, on me l'a déjà exprimé ouvertement).
Si j'ai proposé à ces projets de migrer vers Discourse, c'est parce que je vois bien que les listes de diffusion auxquelles je suis abonné connaissent une fréquentation et un trafic décroissant au fil des ans, y compris au sein de projets qui restent très dynamiques, et que les forums modernes et les messageries instantanées prennent le dessus. Quoi qu'on pense de ces outils, en 2022, ils répondent mieux aux attentes de la plupart des gens. Il appartient dès lors aux projets de s'adapter en proposant à leur communauté les outils aux gout du jour. Offrir les moyens de communication et de travail collaboratif adéquats est un facteur de succès pour un projet libre.
[^] # L’accompagnement au changement
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Comme beaucoup de projets d’évolution d’outils, un des points les plus importants, c’est l’accompagnement au changement – avec le recueil des besoins1 des utilisateurs.
Par exemple, j’ai organisé pas mal de migrations d’outils structurants dans la façon de travailler (Eclipse -> IntelliJ, SVN -> Git + Merge Request, etc). À chaque fois au moins une personne m’a opposé que cette migration ne de devrait pas être faite parce que « un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail) ».
Eh bien, la migration s’est toujours bien passée, et les plus râleurs ne reviendraient en arrière pour rien au monde.
Évidemment, réussir une migration de ce type n’est ni facile ni immédiat. Il y a une longue phase de recueil des besoins, de préparation de la migration, d’explications en amont pour que les personnes concernées puissent s’approprier le projet, d’explication des attendus, d’indication de ce qui sera plus pratique, plus efficace, plus agréable et aussi plus difficile à faire2 et plus complexe. Ensuite il y la bascule proprement dite, et le soutien aux équipes tant que le nouvel outil n’est pas maitrisé – sans jugement ni pression excessive.
Mais, en un mot comme en cent : un usage ou un flux de travail, ça se modifie très bien. Le fait qu’il y ait un usage en place, un outil ou une organisation de travail particulière, ça n’est en rien un argument valable à lui seul pour interdire une modification. C’est un argument parmi d’autres dans une procédure de décision de changement, mais certainement pas le seul.
On parle bien besoins et pas envies des utilisateurs. Le classique, c’est l’utilisateur qui va faire des pieds et des mains pour exiger que rien ne change parce qu’il n’a pas envie de changer sa façon de faire, alors qu’il pourrait être beaucoup productif et de façon beaucoup plus confortable avec un nouvel outil. Un autre classique, c’est les demandes de gadgets. Il y a aussi toute cette catégorie d’irritants dont les gens n’ont même pas conscience et qu’ils ne peuvent donc pas verbaliser, parce que le problème est tellement intégré qu’ils ne savent pas qu’on peut faire différemment. ↩
Note : ça peut être une bonne chose que quelque chose devienne plus difficile à faire. Comme « pousser du code qui ne compile pas sur le HEAD » par exemple. ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: L’accompagnement au changement
Posté par barmic 🦦 . Évalué à 4.
C'est exactement ce qu'a fait Linus Torvald, il a saboté l’environnement de travail des développeurs du noyau en leur changeant de gestionnaire de version, de la destruction d'outils de travail et j'espère bien que toute la communauté de la LKML est monté au créneau pour lui dire ses 4 vérités à se p'tit jeune qui vient leur foutre le boxon.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L’accompagnement au changement
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Le gestionnaire de version historique commençait à être cassé par l'éditeur qui en plus voulait traire les développeurs du noyau. Git a été conçu en tenant compte du cahier des charges publiquement discuté sur la liste et surtout préserve l'essentiel de la façon de fonctionner de la communauté. Du coup, il n'a pas foutu le boxon et personne n'a eu besoin de monter au créneau …en tout cas dans l'univers où je suis, où cet exemple est plus que mal choisi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L’accompagnement au changement
Posté par barmic 🦦 . Évalué à 2.
Et c'est ce que font les projets qui font ce genre de migration. Problèmes rencontrés sur un outil (ou possibilité de faire mieux1), ils discutent, choisissent en fonction et prennent le temps de migrer tranquillement (syndrome NIH en moins).
Ce n'est peut-être pas ce qu'a fait Gnome mais c'est une question de gouvernance du projet pas d'outils ou d'importance de la brique.
comme pour l'adoption de bitkeeper quelques années auparavant ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Les mailing lists c'est pas pratique
Posté par wagaf . Évalué à 4. Dernière modification le 29 octobre 2022 à 15:46.
Les mailings lists m'ont toujours paru très peu pratiques et me semblaient déjà obsolètes quand j'ai découvert Internet au début des années 2000.
Déjà à l'époque, les forums php faisaient bien mieux à tous point de vue, et je ne comprenait déjà pas pourquoi "les anciens" s'obstinaient fièrement avec ce système de communication en mode texte.
Comme dit par un autre commentaire, beaucoup de gens sont intimidés par les mailings lists et ne souhaitent pas les utiliser, mais n'osent pas l'exprimer car la mailing list fait partie du "folklore libriste" et est parfois défendue presque comme une religion (de moins en moins ces jours ci).
Il me semble clair que les projets fonctionnant avec une mailing list se privent de nombreux contributeurs sans s'en rendre compte. Oui, même le noyau Linux.
[^] # Re: Les mailing lists c'est pas pratique
Posté par Watchwolf . Évalué à 3.
Je suis d'accord. Les ML ressemblent à un monstre vu de l'extérieur.
[^] # Re: Les mailing lists c'est pas pratique
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Une réponse de dinosaure : j'ai testé et fait l'effort de créer un compte pour une dizaine de forums (autant d'identifiants et mots de passes à retenir, autant de profils à remplir, et j'en passe) ; et à l'arrivé j'ai juste cessé de contribuer parce-que je ne passe pas mes journées à ouvrir un/une onglet/fenêtre sur chaque forum (à courir après les discussions qui avant venaient à moi) où en plus il fallait jouer de clics dans tous les sens pour trouver les nouveaux messages répartis dans diverses catégories/sections.
Je doute que le noyau Linux et d'autres se privent de gens qui sont plus préoccupés de clignotement dans tous les sens (avec le gaspillage de ressources qui va avec) qu'autre chose.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Les mailing lists c'est pas pratique
Posté par barmic 🦦 . Évalué à 6.
Ça c'est du mépris de classe1. J'ai failli dans ma tête envoyer bouler tout ton message, te moinsser et passer à autre chose. C'est dommage parce que ton argument est intéressant.
Tu as déjà un compte dans chacun des projets actuellement, il t'en faut un pour pouvoir participer aux tickets, il va aussi falloir quelque choses pour que tu ai le droit de pousser du code. Bref créer un compte tu l'a déjà fait, mais dans le web aujourd'hui on ne crée plus de compte, on s'appuie sur un compte que tu as déjà. Éventuellement on te demande des trucs en plus, mais c'est rare. Et non tu n'es pas obligé de passer par un GAFAM, linuxfr.org le propose.
Je ne suis pas certain de ce que tu dis mais, je ne connais pas de forum qui n'ai pas option "envoyer une notification par mail lorsque je reçois une réponse".
Si tu parle de messages qui ne te sont pas destinés particulièrement. Je comprends. Pour la montée en charge avec le nombre de projets (j'imagine a faible activité), ça n'est pas confortable.
Je n'ai jamais utilisé discuss mais sur phpbb je naviguais dedans comme 5 j'aurais navigué dans mutt. De plus il faut voir la communauté, celle de gnome utilise probablement plus evolution ou thunderbird que mu4e, je ne pense pas que les clics leur donne des boutons.
rapidement comme je ne doute pas que ça va tiquer. Tu présente ceux qui préfèrent le web aux ML comme des "gens qui sont plus préoccupés de clignotement dans tous les sens". Si ce n'est pas une façon de mépriser une classe ou une catégorie de personnes. Bref ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les mailing lists c'est pas pratique
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Non, je dénonce un triste constat de ces trucs web : ça fini presque toujours avec des bannières de pub sous divers prétextes. D'un autre côté, j'avais remarqué que la préférence de ces plateformes web était souvent pour pouvoir mettre des images alors tandis que les listes refusaient les pièces jointes (sans compter les limitations de poids dans les messages.) Le même public, qui ne comprend pas qu'on n'accepte pas les mails en HTML et depuis OE, fustigera bientôt le web et sa mode markdown parce-que ne permettant pas d'écrire son texte dans la taille (mais certaines personnes détournent déjà les titres) et la couleur de son choix.
Il ne saurait être question de mépris de classe puisqu'on retrouve ces traits dans toutes les catégories sociales et à tous les niveaux et tout âge. S'il y a mépris, ce serait plutôt dans l'autre sens, en assénant que le développement du noyau gagnerait on ne sait quoi en se fardant en plus d'un forum web (parce-que n'ayant pas déjà assez à faire ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Les mailing lists c'est pas pratique
Posté par barmic 🦦 . Évalué à 3.
Qui a dit ça ? Je vois des gens parler de leur expérience dans l'une des directions ou l'autre. Mais y associer des valeurs je ne le vois que dans un sens (tu ne me fera pas croire que parler des gens "préoccupés de clignotement dans tous les sens" n'est pas péjoratif par exemple).
Les communautés font ce qu'elles souhaitent en choisissant via leur modèle de gouvernance qui tu es frustré que des projets font ce genre de choix c'est peut être plus ça qu'il faut interroger que l'outil.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Les mailing lists c'est pas pratique
Posté par BAud (site web personnel) . Évalué à 3.
il y a au moins le forum de LinuxFr.org bon il y aurait les flux RSS pour avoir au moins les nouvelles entrées de forum (mais pas leurs commentaires.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.