LinuxFr.org se veut être une référence incontournable de l’actualité autour de GNU/Linux et du logiciel libre. Ses contenus, au premier rang desquels les dépêches sont produits par la communauté. S’ils attirent de plus en plus de visiteurs, ils sont rédigés par une base de contributeurs de plus en plus restreinte.
Pour redynamiser les contributions, l’équipe en charge du site perçoit bien qu’il est possible de l’améliorer (comme tout logiciel à vrai dire) mais n’a pas forcément le savoir‐faire nécessaire pour revoir en profondeur sa conception. C’est là que la communauté intervient. La communauté, c’est aussi toi lecteur, et on va te mettre à contribution !
[NdM] l'enquête étant close, le formulaire chez Framasoft n'est plus accessible
Sommaire
Contexte
Du haut de ses dix‐neuf ans, LinuxFr.org est en pleine force de l’âge ! Animé uniquement par des bénévoles depuis sa naissance, le site peut s’enorgueillir de quelque 99 000 contenus (articles d’actualité, billets de blogs, pages de wiki…) et de la bagatelle de 1,7 million de commentaires ! Aujourd’hui, le site compte près de 3 000 comptes actifs.
L’équipe qui porte actuellement le site témoigne d’une très très grande attention à l’expérience utilisateur. En particulier, elle est soucieuse de l’accueil des nouveaux venus et cherche les moyens de favoriser leur implication. Les contributions, mêmes les plus modestes, sont reconnues : un merci ça n’a l’air de rien, mais ça change tout. Le courriel indésirable est filtré efficacement — Ah, parce qu’en fait, il y a du spam !? Donc, voilà, le travail et les réflexions qui ont lieu autour de LinuxFr.org ne sont pas que techniques, loin s’en faut.
L’expérience utilisateur (« UX », dans les milieux branchouilles) ça va au‐delà du seul site Web : ça recouvre un ensemble d’interactions plus large. Par exemple, les personnes qui annoncent un évènement sur l’un des quatre Agendas du Libre bénéficieront d’une audience étendue grâce à une exportation automatique depuis l’agenda vers LinuxFr.org ! Autre exemple : un canal IRC (#linuxfr sur freenode) est disponible, sur lequel on peut retrouver une fraction de la communauté. Les discussions qui ont lieu sur ce canal, tout comme celles qui ont lieu dans les commentaires d’un article, peuvent avoir un effet sur le ressenti des visiteurs et être un facteur dans leur (non‐)participation future.
Allo Houston, on a un problème
Malgré tout, les chiffres montrent que la base des contributeurs s’étiole au fil des ans.
Avez‐vous été bien accueilli ?
Lorsqu’on a commencé à travailler sur le site, on a rapidement pu identifier un certain nombre de bricoles qui rendaient le site visuellement peu accueillant. Attention, âmes sensibles, s’abstenir.
Des captures d’écran avec du fuchsia par‐dessus.
Plusieurs de ces lacunes ont été corrigées depuis. Par exemple, le bandeau de navigation est désormais plus court (les liens sondages, suivi et plan ont été retirés, un lien rédaction a été ajouté) et les dépêches reprenant l’Agenda du Libre sont tronquées sur la page d’accueil. Cependant, les travaux à mener sont substantiellement plus importants.
Périmètre des journaux
Les articles publiés dans la section journaux ne sont pas toujours en rapport avec l’objet de LinuxFr.org. Il n’est pas rare alors de voir un utilisateur avisé reprocher à l’auteur le caractère hors‐sujet de l’article. Il n’est pas rare non plus de voir un autre utilisateur avisé, lui aussi, signaler au premier l’aide détaillant l’utilité des différentes sections du site. Alors, l’explication est simple, à chaque fois, c’est que le second utilisateur est plus avisé que le premier ?
Pas si sûr… Lorsqu’on cherche à créer un nouveau journal, le message suivant est affiché :
Des règles de modération sont applicables aux journaux (et au reste du site).
Et le lien amène à une page quasiment intégralement dédiée aux règles valables sur les dépêches. Les deux utilisateurs ont également raison, c’est le site Web qui a faux.
Cette confusion entre les journaux et les dépêches est favorisée par la terminologie elle‐même ! Journaux et dépêches, c’est quand même très similaires. Les habitués s’en sont accommodés, mais les autres ? Il n’est pas évident que « dépêches » ne renvoie pas à « journaux » qui, lui, renvoie à « journaux personnels ». Pour clarifier, on pense qu’il serait plus évocateur de parler de « blogs », sur lesquels les auteurs peuvent publier des « billets ».
Les rubriques sens dessus dessous
Autre exemple sur les réflexions à mener. Prenons les dépêches. Nous avons en moyenne plus d’une dépêche publiée par jour, après avoir été soumises à la diligence des modérateurs. Chaque dépêche est placée dans une « section », ce qui permet de regrouper les articles traitant d’un même domaine.
Enfin, en théorie, car on dénombre exactement 77 sections ! En pratique, celles‐ci sont plutôt utilisées pour agrémenter visuellement le site : à chaque section correspond une image qui figurera en haut à gauche de chaque article.
Et puis la terminologie, encore ! On parlait de sections pour distinguer les grandes partie du site (dépêches, forums, wiki…), parler de rubrique permettrait d’éviter des confusions ?
En plus de ces (trop) nombreuses sections rubriques, des étiquettes (tags) permettent de faire des passerelles entre des articles ayant des thématiques en commun. Plusieurs thématiques pouvant être abordées dans un même article, il n’est pas choquant qu’on ait un nombre élevé d’étiquettes.
Cependant, celles‐là sont définies par la communauté de manière déconcertée et de très nombreux doublons sont apparus au fil du temps. Nous avons des thématiques pour lesquelles la fonctionnalité est loin d’être rendue de manière optimale, si elle n’est pas totalement cassée. On peut étiqueter (« taguer ») mille fois un jeu vidéo, mais on peut pas étique… Si, on peut étiqueter une fois… Non, on ne peut pas étiqueter mille fois un jeu vidéo, mais on peut étiqueter mille fois un jeu vidéo. On peut étiqueter mille jeux vidéo une fois.
Plus tard dans le processus, on expérimentera peut‐être comment trier collectivement les articles…
Objectif inatteignable
Rappelons que l’objectif premier est de favoriser et encourager la production d’articles sur le site. Considérons le très intéressant espace de rédaction collaborative. Petit test utilisateur informel. À la question, « cette page te donne‐t‐elle envie de participer ? », la réponse retournée était « c’est quoi ce truc en haut à droite ? Un classement des personnes qui contribuent le plus ? Je sais que je ferai jamais partie de la liste, du coup c’est même pas la peine d’essayer. »
Quelques chiffres
On se demandait quels appareils étaient utilisés pour parcourir LinuxFr.org, si des fonctionnalités comme le téléchargement des articles au format EPUB étaient bien utilisées, ou encore quels chemins les gens suivaient pour accéder aux contenus.
Bonne nouvelle, une section statistiques sur le site fournit plein de chiffres ! Des chiffres, ça peut être pratique pour objectiver les choses, encore faut‐il être capable de collecter les données pertinentes et de les interpréter. Et, moi, lorsque je vois un tableau et même lorsque j’entends parler d’indicateurs et autres tableaux de bord, je pense très fort à ça :
Qu’est‐ce qui a trois bras, un seul chapeau, deux chemises et une veste, un foulard, un pistolet et quatre oreilles ?
Mauvaise nouvelle, certaines des infos que l’on recherchait ne figuraient pas dans la section statistiques. On a quand même pu compter sur Benoît Sibaud qui est allé piocher dans les journaux pour nous aider à y voir plus clair.
Attention, toutes ces cascades sont réalisées par des professionnels bénévoles, ne faites pas ça chez vous.
Les liens de téléchargement
Sur le téléchargement aux format EPUB ou Markdown, voici ce que Benoît a pu comptabiliser :
- sur les dépêches, pour 1,9 millions de hits, on compte 212 000
.mdet 215 000.epub;- sur les journaux, pour 1,4 millions de hits, on compte 173 000
.mdet 169 000.epub.
À la louche, ça voudrait dire que pour une consultation sur cinq, les articles sont téléchargés pour être lus ultérieurement, en ligne. On soupçonne cette proportion d’être largement surestimée, notamment du fait que la recherche du site renvoie systématiquement vers des .md.
Quels chemins suivent les visiteurs pour accéder à ces fichiers ?
- dépêches :
7 487 dépêches
.mdvenant de la page d’accueil ;
8 129 dépêches.epubvenant de la page d’accueil ;
19 dépêches.mdvenant de la liste globale des dépêches ;
18 dépêches.epubvenant de la liste globale des dépêches.
- journaux :
8 journaux
.mdvenant de la page d’accueil (ils sont peu nombreux à avoir les journaux en page d’accueil…) ;
0 journal.epubvenant de la page d’accueil ;
63 journaux.mdvenant de la liste globale des journaux ;
58 journaux.epubvenant de la liste globale des journaux ;
327 journaux.mdvenant de la page d’un utilisateur ou de la liste des journaux d’un utilisateur ;
428 journaux.epubvenant de la page d’un utilisateur ou de la liste des journaux d’un utilisateur.
Fait intéressant : les dépêches sont très téléchargées depuis la page d’accueil, mais très très peu téléchargées depuis la section Dépêches. Les journaux, eux, sont le plus souvent rapatriés depuis les pages utilisateur qui listent les contenus publiés par un compte donné.
Les grandes parties du site
Nous avons également les statistiques d’utilisation des différentes parties du site :
570 000 sur la page d’accueil ;
87 000 sur la liste des dépêches ;
122 000 sur la liste des journaux ;
43 000 sur la liste des forums ;
6 000 sur l’accueil du wiki ;
2 000 sur l’espace de rédaction.
Sachant que la page d’accueil ne présente à peu près rien d’autre que des dépêches, il y a un déséquilibre flagrant de visibilité entre les différentes parties. On observe un rapport de 1 à 4 entre dépêches et journaux, et un rapport de 1 à 100 entre la liste des dépêches et l’accueil du wiki !
Terminaux utilisés
On s’est aussi demandé ce qu’utilisaient les visiteurs pour parcourir le site. Ordinateur de bureau ? Ordiphone ? Tablette ? Quelle taille d’écran ? Quelle résolution ?
Pour le coup, on est rentré brocouille, comme on dit dans le Bouchonois. On procèdera autrement.
Améliorons l’expérience utilisateur !
Afin de mieux répondre aux attentes des utilisateurs que vous êtes, on va d’abord se demander qui vous êtes. Pourquoi venez‐vous (et revenez‐vous !) ? Quand et comment ? Ce qui vous plaît et ce qui vous déplaît ? Pour ça, on a créé un petit formulaire chez Framasoft (merci Framasoft !). La plupart des questions sont ouvertes, c’est parce qu’on veut que vous puissiez formuler les choses telles que vous les voyez.
Pour recueillir un maximum d’informations pertinentes sans harasser les participants, nous avons pris le soin de trier les questions par ordre décroissant d’intérêt. Hélas, FramaForms ne permet pas de soumettre des résultats partiels, alors si vous en avez vite marre, il faudra faire « suivant, suivant… » jusqu’à atteindre le bouton soumettre !
Cette enquête est ouverte à toutes les personnes qui visitent le site. Des lecteurs irréguliers aux rédacteurs forcenés en passant par les vieilles moules et les modérateurs, toutes les participations seront étudiées !
On essaiera de dégager quelques profils‐types et scénarios d’utilisation qui impacteront la prochaine version de LinuxFr.org.
Cliquez donc sur le lien pour participer à l’enquête.
Aller plus loin
- Enquête auprès des utilisateurs de LinuxFr.org (892 clics)
# Terminologie et taille des contenus
Posté par Arthur Accroc . Évalué à 10.
En effet.
Je pense de plus qu’une terminologie différenciée suivant la taille des contenus permettrait de ressusciter les contenus courts (et souvent plus frais que les articles fouillés qui mettent plus de temps à être écrits, les deux ayant leur intérêt), avec une possibilité pour ceux qui ne les apprécient pas de ne pas les afficher plutôt que de râler ou d’inutiler.
Je reproduis le petit tableau que j’avais déjà proposé :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Terminologie et taille des contenus
Posté par claudex . Évalué à 4.
Pour qu'on en garde une trace, il vaudrait mieux le mettre dans le suivi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Suivi
Posté par Arthur Accroc . Évalué à 2.
C’est fait.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 10.
Ce qui me manque le plus sur LinuxFR c'est la possibilité d'éditer ses propres contenus. J'essaie autant que possible d'avoir des échanges construits et intéressants, et c'est très frustrant quand on relit une conversation de voir des typos, des petites fautes ou défauts de formulation dans ses propres messages et de ne pas pouvoir les corriger. (C'est évidemment encore pire pour les journaux, mais le problème se pose dans les deux cas.)
Tous les autres sites que je fréquente (à part les mailing-lists) permettent cela, et ça se passe sans problème. LinuxFR est en retard là-dessus et, pour moi, cela nuit beaucoup au confort de participation.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Zenitram (site web personnel) . Évalué à 4.
On peut éditer, mais que pendant quelques minutes. Sans doute pour éviter de supprimer une chose qu'on n'assume plus mais dont les réactions sont basées dessus donc sont biaisées du fait de la modification.
La solution est alors de permettre de voir les version précédentes (ça se fait sur certains sites), mais c'est du taf à intégrer correctement.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 6.
Permettre l'édition pendant 5 minutes est mieux que rien, mais ça ne me convient pas. Je repère souvent des modifications à faire après-coup pendant une discussion, quand la limite est passée. C'est évidemment encore plus le cas pour les journaux, où je peux mettre du temps à repérer une faute ou à ce qu'elle me soit signalée.
Je serais prêt à aider à implémenter cette fonctionnalité.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Kerro . Évalué à 8.
Le délai court évite qu'un message à l'origine d'une discussion soit ensuite modifié afin de faire passer les autres pour des imbéciles.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 7.
Encore une fois, sur aucun des autres sites que j'utilise, et qui permettent tous l'édition, cela n'est vu comme un problème. Un soucis de maturité des comportements sur LinuxFR ? De toute façon, garder l'historique des éditions (permettre de consulter les anciennes versions du message) élimine cette inquiétude.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Ce n'est probablement qu'une coïncidence, mais je suis tombé sur ce fil de discussions aujourd'hui : https://news.ycombinator.com/item?id=15524640. L'auteur du commentaire initial est critiqué par une autre personne pour avoir édité son commentaire :
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 22 octobre 2017 à 21:35.
Vous devriez lire en entier les commentaires auxquels vous répondez, pour pouvoir y répondre honnêtement, par exemple en expliquant en quoi l'affichage de l'historique (discuté comme manière d'éviter les problèmes dont vous parlez, ben oui les gens à qui vous répondez connaissent déjà ce problème) ne résoudrait pas les problèmes que vous soulevez (vous faites comme si les gens n'y avaient pas déjà réfléchi).
Par exemple, l'exemple donné (ycombinator) n'a pas d'historique, alors que les gens auxquels vous répondez disent qu'un historique est le moyen de montrer aux gens que la personne aurait modifié son commentaire pour "effacer" des problèmes.
c'est dommage de bloquer avec des arguments connus sur lesquels les gens ont déjà répondu en avance sans daigner contre-argumenter sur la solution proposée, ça n'aide pas à un débat objectif. Parce que ça donne l'impression de juste ne rien vouloir changer, sans être prêt à réfléchir.
(en parlant de choses à améliorer, peut-être trouver un moyen que les gens répondent aux commentaires qu'ils ont lu en entier et interdire les commentaires qui ne font que donner un argument déjà répondu dans le commentaire auxquels ils répondent? bon, va falloir une IA pour ça)
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 8.
Boarf. Je pense que Bruno répondait à l'aspect "sur les autres sites ça ne me pose pas de problème" (je ne fréquente pas Hacker News donc ce n'est pas incompatible). Par ailleurs si tu vas lire la discussion qu'il cite, clairement la personne qui a écrit ce message est hyper-agressive (ce qui s'est passé c'est que le type qui a édité a ajouté "Clarification: …" et pas "Edit: …", ce qui est une erreur de jugement mais pas profondément malhonnête), et que d'autres gens dans la discussion sont trop agressifs aussi. À partir de là, il y aurait pu avoir un problème quoi qu'il arrive, dans un site qui ne permet pas l'édition (l'auteur original aurait posté un second commentaire et le râleur serait venu dire "non mais tu changes d'avis d'une fois sur l'autre c'est super malhonnêtre") ou dans un site avec historique (une personne aurait pu ne pas aller regarder l'historique et lancer une bataille de toute façon).
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Mais je ne bloque pas. Si quelqu'un m'envoie un patch pour pouvoir éditer des contenus avec un historique, je l'intégrerais avec plaisir.
On a de l'historique sur les dépêches dans l'espace de rédaction et ça n'empêche pas les gens de venir s'y chamailler. Mais je ne réfute pas l'intérêt de pouvoir éditer des journaux ou commentaires. C'est juste que sur LinuxFr.org, comme sur Hacker News, il y a des commentaires techniques très intéressants mais aussi beaucoup de commentaires inutilement agressifs. Et que l'on soit en possibilité de modifier ses commentaires ne change pas grand chose : il y a aura toujours des gens dans les deux camps pour venir râler. Je pense que pouvoir éditer ses commentaires va légèrement augmenter cette proportion, mais que ça reste acceptable au vu de l'intérêt de la fonctionnalité. Par contre, très clairement, je n'ai pas envie de passer du temps à coder sur ça, il y a plein d'autres choses dans le suivi qui me semblent bien plus importantes (et d'autres d'ailleurs qui ne sont pas dans le suivi).
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 6.
C'est la première fois que je lis ça et c'est nouveau pour moi. On verra quand j'aurai du temps.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Kerro . Évalué à 10.
C'est une solution qui ajoute de la complexité : je n'ai pas envie d'être obligé de vérifier l'historique des messages avant d'y répondre, c'est ingérable.
Quel pourcentage de messages ont "besoin" d'être édités ? A comparer avec la complexité engendrée.
Un argument que j'aime bien : ne pas avoir de possibilité d'édition incite à réfléchir correctement. Je trouve que ça donne des discussions qui sont de meilleur niveau.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 5.
À l'usage, pour utiliser cela sur les autres sites aussi, je confirme que c'est très utile. La variable d'ajustement pourrait aussi être le délai de grâce. Sur certains sites, ce délai est de trois jours. C'est très pratique pour relire ses commentaires à tête reposée et sous un autre angle. Je pense que ce n'est qu'après 24 heures de délai au moins (et une bonne nuit de sommeil) qu'on peut vraiment reconsidérer ses propos avec l'œil d'un « lecteur » et non d'un « relecteur ».
Paradoxalement, c'est justement le fait que ce pourcentage soit faible qui va rendre la chose gérable (et d'un autre côté, si tout le monde sollicitait en permanence les modérateurs pour modifier tous les messages du site, alors ça justifierait aussi la mise en place de cette facilité).
Personnellement, j'ai aussi implémenté cette fonction dans le micro site web que j'ai fait pour l'association de mon quartier (avec les messages privés dont je parle dans un autre commentaire). Je fais cela « à la Git », c'est-à-dire que je remplace entièrement un commentaire par un autre même si la modification est minime, ce qui veut dire qu'en ce sens, l'opération n'est pas différente de poster un nouveau commentaire. Et comme mon éditeur est naturellement fait pour faire une prévisualisation (qui elle, n'est pas remise en cause), alors je n'ai besoin de pratiquement aucun code supplémentaire pour reprendre un commentaire existant.
Dans un premier lieu, seule la date de dernière édition est discrètement signalée dans une note en bas du commentaire, et le fait que l'opération soit courante mais pas fréquente fait que cela attire automatiquement l'œil du lecteur quand c'est le cas. Ensuite, les anciens commentaires sont toujours dans la base. Ils sont juste déréférencés parce que le dernier en date remplace toujours le précédent. Donc, au point de vue code, ça ne pose aucun problème.
Ensuite, il me suffit d'une simple table à deux colonnes pour faire un chaînage parent→enfant pour remonter l'historique des modifications. Ça resterait déjà tout-à-fait exploitable si la totalité des commentaires des 15 dernières années avaient un CV long comme le bras (cas des pages Wikipédia, par exemple), mais sur un forum des discussions. Ça va effectivement concerner peut-être 3 à 5 pourcent des commentaires, dont la majorité n'auront qu'une seule modification.
Donc en résumé — POUR l'AVOIR FAIT — je confirme que c'est relativement facile. :)
Mouais mais non. Ça, ça n'est vrai que jusqu'à un certain niveau. Ensuite, au bout d'un moment, ça fatigue l'utilisateur, surtout quand il s'agit d'une régression. Prévenir les gens pour qu'ils ne fassent pas de faux pas, c'est une bonne chose, s'arranger pour que, techniquement, ils ne puissent pas en faire, c'est encore mieux.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Thomas Douillard . Évalué à 1.
Et une culture chez certains contributeurs vis à vis de la sécurité je pense. Avec une idée « le seul moyen de corriger une faille c’est de l’exploiter » qui incite a des comportements complètement non naturels genre des comptes problématiques qui apparaissent opportunément pour troller. Ça incite à des postures excessivement défensives. Genre par crainte de de comportement détester jouer une caricature à la puissance 10 dudit comportement afin de pousser à l’interdire.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par groumly . Évalué à 10.
Si on va par la, faut pas non plus autoriser le changement du pseudo, parce que ça fout en l’air les mentions.
Y’a une réponse vachement plus simple à ce problème: don’t feed the troll. Si y’a un mec suffisament con pour changer radicalement son message après avoir lancé une longue discussion, Ben discutes pas avec lui. Il tkaura une fois, peut être deux. Après t’arrêteras, et lui aussi du coup.
C’est vraiment un cas à la marge, et qui va affecter des discussions déjà pourries par un keke dont le but est pas de discuter mais de faire chier le monde. Édition ou pas, ton troll il pourrira le fil quoi qu’il arrive.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par rewind (Mastodon) . Évalué à 4.
C'est triste ton avis sur Zenitram
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par robin . Évalué à 5.
Sur reddit si on modifie son commentaire en moins de (1 minute?), il est affiché tel-quel, sinon il y a une petite étoile. C'est donc facile de savoir si le commentaire a été modifié. Dans tout les cas entre un commentaire modifié car non-assumé, ou supprimé car non-assumé, le résultat est le même.
bépo powered
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 2.
Ça se fait avec vBulletin aussi. Un commentaire rapidement modifié ne laisse aucune trace (je ne saurais dire si cela tient compte du fait qu'il y ait ou non des réponses), sinon la date de dernière modification est ajoutée, et cliquer dessus donne accès à l'historique et au différentiel des changements (à la Wikipédia).
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par totof2000 . Évalué à -1.
Juste une question : quand tu parles à quelqu'un, est-ce que tu as la possibilité de revenir sur ce que tu as dit pour le changer ? Je ne crois pas …. Par contre il serait peut-être judicieux d'avoir la possibilité de faire un ajout à un commentaire lorsqu'on se rend compte qu'on a mal formulé un propos, ou que l'on a été assez agressif pour essayer de corriger le tir.
Parce que même l'historique, ça ne règle absolument pas le problème. Pour que ce soit utilisable, il faudrait que lorsque l'on lit la réponse à un commentaire corrigé, on puisse avoi la version d'origine et la version corrigée en simultané. Mais ça devient vite ingérable si on ne limite pas le nombre de changements qu'une personne peut faire.
Au pire, en cas de grosse erreur, les modérateurs peuvent aider à corriger. Et comme dit ailleurs, ça pousse les gens à assumer ce qu'ils ont dit.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 7.
Je ne vois pas le rapport. Depuis quand le but des commentaires est d'imiter exactement une conversation humaine ?
Quand je parle à quelqu'un, normalement il n'y a pas des dizaines de personnes qui vont venir derrière ré-écouter ce qu'on a dit, aujourd'hui ou dans 10 ans, et qui bénéficieraient d'une clarification de la conversation.
Si on peut se donner une fonctionnalité qui améliore les discussions par rapport à une conversation physique, pourquoi s'en priver ?
Quand on voit le message de quelqu'un qui a été édité, on n'a pas en général besoin d'aller consulter l'historique. L'historique n'est là que si on a l'impression que certaines personnes ont répondu à une version précédente du message et qu'on veut être sûr de bien comprendre l'histoire—en particulier il sert de témoin à une utilisation abusive de l'édition. Ce serait un cas ultra-minoritaire, et non pas systématique.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 4.
En fait on peut modifier ses messages, mais le délai de grâce est un peu être un peu trop court :
Autre chose qui existait jadis et qu'il serait agréable de récupérer : les messages privés.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par RyDroid . Évalué à 0.
En quoi cela pourrait être utile ? En quoi ça se différencie suffisamment des emails et de XMPP ?
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 5.
Je suis d'accord avec toi sur le fait que les emails sont plus pratiques, mais ils sont quasiment inutilisables sur LinuxFR puisque le site ne permet pas aux membres de montrer une adresse email aux autres. J'ai ouvert une entrée de suivi il y a des années à ce sujet, Permettre aux membres de rendre leur adresse mail publique, mais il semblerait que cette fonctionnalité, qui me semble basique, n'est pas assez convaincante ?
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par RyDroid . Évalué à 7.
Rendre l'email publique, même uniquement aux membres, peut être problématique. Néanmoins un formulaire pour envoyer un email peut être pratique (avec le "Reply-To" qui va bien) puisqu'il cache l'email et permet de répondre ou pas ensuite par email.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 5.
Il suffit de laisser les gens choisir de donner un email à afficher (ou pas, et pas forcément celui utilisé pour communiquer avec LinuxFR-le-site). Si les gens ne veulent pas de spam, ils ne mettent pas d'email, et s'ils veulent un pseudonyme précis ou quoi ils choisissent la bonne adresse email à montrer. C'est expliqué dans l'entrée de suivi.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 2.
Ce serait donc un « minimum », si l'on peut dire, surtout dans la mesure où cela existait ici avant et que ça existe également partout ailleurs.
Et à partir du moment où on a un formulaire permettant de relayer instantanément un message vers l'adresse e-mail (conservée confidentielle) d'un membre, et que d'autre part, on a tout un système de conservation des messages publics (les commentaires des discussions), alors il ne manque vraiment pas grand chose pour implémenter un vrai système de messages privés.
Surtout que les MP basés sur l'e-mail déclarée d'un membre implique que l'expéditeur ait lui aussi une adresse valide qui sera automatiquement utilisée comme adresse expéditrice, ou à tout le moins en tant que Reply-To.
Et justement, comme cela implique d'utiliser le nom de domaine de l'hébergeur de l'adresse e-mail, cela nécessite en fait d'envoyer le premier mail en tant que noreply@linuxfr.org ou quelque chose d'assimilé. Il est largement plus sympa d'avoir des MP pour communiquer des infos confidentielles entre membres d'un même site sans avoir à révéler son adresse personnelle.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 2. Dernière modification le 26 octobre 2017 à 09:52.
Personellement je préfère pouvoir passer par les emails que par des MPs LinuxFR. Les MPs LinuxFR seront forcément moins confortables à l'édition, ne seront pas archivés dans ma boîte mail et donc pas cherchables, vont manquer de 36 fonctionnalités utiles (conversations filées, facilité d'ajouter d'autres personnes (peut-être pas membres de LinuxFR !) dans la conversation, pièces jointes, signatures GPG), avoir une limite de nombre de messages qui va un jour me casser les pieds… la liste est longue et il facile de se convaincre que ce ne sera jamais aussi bien que de laisser les gens utiliser des emails (ou XMPP s'ils préfèrent, etc.). Je ne connais aucun site dont les messages privés sont plus agréables à utiliser que les emails.
(Et on n'a pas besoin de révéler une "adresse personnelle", on donne l'adresse qu'on veut. Je peux me créer une boîte mail 'gasche-linuxfr@…' chez n'importe quel fournisseur email et l'utiliser. Si ça amuse les gens de linuxfr, ils peuvent même monter un serveur mail @linuxfr.org et donner des comptes aux membres qui le demandent.)
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 5.
C'est exactement cela qui est rédhibitoire pour moi. Je gère déjà sept adresses e-mail un peu partout et même avec un client dédié, aller créer une adresse PAR forum pour bénéficier des MP, ce n'est pas acceptable. Surtout à la volée !
Je ne comprends pas que tout le monde trouve normal de s'exprimer publiquement mais à une personne donnée dans un fil de discussion (via les réponses) et de ne pas pouvoir faire un aparté quand on a une information confidentielle à transmettre.
Surtout que ce n'est pas du tout mutuellement exclusif : quand il y a des MP, il y généralement moyen d'être également prévenu par e-mail – si on le souhaite – et il y a un bouton pour les exporter. Même moi qui ait écrit un serveur complètement from scratch (sur du PHP/PostgreSQL) parce que notre hébergement est trop petit pour y coller quoi que ce soit de sérieux, j'ai mis en place cette fonctionnalité. Pour une population de 60 personnes environ.
Ça existe absolument partout et ça fonctionnait très bien ici aussi.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par gasche . Évalué à 4.
La différence, il me semble, c'est qu'ajouter la fonctionnalité "mettre ici l'adresse mail à montrer sur son profil" est assez facile, et demande beaucoup moins d'efforts qu'implémenter les MPs. C'est pour ça que je pense que c'est une bonne priorité. Mais après si toi tu tiens aux MPs et tu n'as absolument pas envie de montrer une adresse email que d'autres personnes risqueraient de connaître déjà, n'hésite pas à ouvrir un ticket de suivi et/ou à envoyer un patch.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 4.
Je fréquente linuxfr.org depuis 1999. J'ai déjà ouvert quelques tickets qui ont fini par être implémentés, dont le [^], évoqué dans un autre commentaire, et qui est en place depuis Templeet.
J'ai contribué en postant une ou deux dépêches, j'ai fait un certain nombre de traductions dans les dépêches noyau, et j'avais proposé les CSS Nightgrey et Springtime en leur temps, toujours sous Templeet (la dernière m'a demandé environ 80 heures de travail, à l'époque. Les CSS éponymes actuelles ne sont pas les mêmes et ont été écrites par d'autres personnes).
Pour le patch MP, tu as tout-à-fait raison en soi et la seule raison pour laquelle ce n'est pas encore proposé, c'est que je ne connais RIEN au Ruby. Il y a des moments où on ne peut plus courir tous les lièvres à la fois. Je suis principalement codeur C, et j'ai pourtant déjà fait pas mal de web.
Par contre, et c'est une vraie question, puisque tu utilises cet argument pour conclure ce fil, peux-tu nous indiquer si tu as déjà toi-même contribué au site (autrement que par les commentaires, ce qui est déjà beaucoup) et si oui, dans quelle mesure ?
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . Évalué à 3.
J'ajoute également, comme dit plus haut (et parce que mon commentaire qui a HUIT minutes ne peut plus être édité) que j'ai écrit un site web entier en PHP (+ PostGreSQL) et implémentant un forum organisé en arbre (comme celui de DLFP) avec possibilité d'édition et messages privés.
Ce n'est pas un exploit en soi, mais ça répond à ta question, dans le sens où je l'ai déjà écrit. C'est juste que ce n'est pas en Ruby. :)
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par TutoMaker . Évalué à 4. Dernière modification le 23 octobre 2017 à 15:16.
J'ai toujours été étonné de ne pas voir cette fonctionnalité (les MP) sur LinuxFR, malgré le fait que je la trouve essentielle à une communauté.
Car tout le monde n'a pas XMPP, et la plus part des adresses mail sont hébergées chez big brother et ne servent qu'à s'inscrire sur des sites ?
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par RyDroid . Évalué à -1.
Si le système n'apporte rien de plus que XMPP ou l'email, pourquoi diable ré-inventez la roue (et la maintenir), autant ré-utiliser en configurant potentiellement pour ne pas pouvoir communiquer avec un autre serveur (il me semble que c'est par exemple ça que fait Facebook avec Facebook Messenger qui est basé sur XMPP si je me souviens bien).
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Maclag . Évalué à 5.
[Mode manager]
Je note donc les action items suivants pour atteindre notre but qui est un linuxfr.org plus convivial et accueillant:
[/Mode manager]
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par kantien . Évalué à 4.
Tu sous-entend que pasBillpasGates devrait administrer un serveur mail et offrir une adresse à chaque membre de linuxfr ? :-D
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Maclag . Évalué à 3.
C'est une piste, mais si pasBillpasGates a un jeune frère, il ne pourra toujours pas profiter de linuxfr. Il nous faut une solution plus universelle.
# Coquilles dans le formulaire
Posté par Olivier HUMBERT (site web personnel) . Évalué à 2.
"télécharger les article au format .md " -> article*s*
"les messagerie" -> messagerie*s*
https://librazik.tuxfamily.org - http://linuxmao.org - https://liberapay.com/trebmuh
[^] # Re: Coquilles dans le formulaire
Posté par mjourdan . Évalué à 1.
C'est corrigé. Merci pour le signalement, et pour les réponses au sondage.
Et toutes mes félicitations pour tes attributs pareils à ton age !
# Titre en français
Posté par Maderios . Évalué à 10.
"Expérience utilisateur" est la traduction littérale de l'expression anglaise "Experience user". Dans le contexte de cette page, un mot français peut remplacer cet anglicisme: l'ergonomie.
Ce qui nous donne:
PS: Je n'ai rien inventé
http://www.linuxfr-france.org.invalid/~nquiniou/module_si1/si01/ch41s05.html
[^] # Re: Titre en français
Posté par mjourdan . Évalué à 5.
Absolument !
Je ne pense pas. Bien sûr, l'ergonomie est un l'un des aspects sur lequel nous allons le plus travailler. Mais l'expérience utilisateur ne s'arrête pas là. Outre ce qu'on a évoqué dans la section « Contexte », on peut citer l'aspect visuel du site. Et les réponses au sondage que l'on a pu collecter tendent à pointer comme principaux facteurs de découragement à participer les éléments suivants : les commentaires cassants auxquels on s'expose ou un trop haut degré de spécialisation qui serait requis pour participer. Ce n'est donc pas seulement vers l'ergonomie qu'il faut orienter nos efforts pour dynamiser les contributions.
[^] # Re: Titre en français
Posté par Gilles Coulais (site web personnel) . Évalué à 0.
Ou pas. On parle de User Experience, pas l'inverse. Mais c'est une simple péripétie temporelle
[^] # Re: Titre en français
Posté par Davy Defaud . Évalué à 6. Dernière modification le 22 octobre 2017 à 23:18.
Voilà un bel exemple de petite contribution. ;-)
J’ai effectué la correction du titre et du contenu, et j’ai intégré le terme « expérience utilisateur » avec son sigle UX précisé entre parenthèses, car ils sont tout aussi branchouilles. Entre nous, c’est tout de même moins choquant que « l’expérience digitale », que notre ami Linus a très bien résumée sur cette photo :
Cependant, comme cela a déjà été précisé, « expérience utilisateur » est la traduction de « user experience » et non de « experience user », qui ne veut rien dire, si ce n’est que ça ressemble à « experienced user », un utilisateur expérimenté.
[^] # Re: Titre en français
Posté par mjourdan . Évalué à 10.
Dans les réponses à l'enquête, plusieurs personnes on déploré les pinailleries sur le bon usage de la langue comme étant contre-productives. Quelqu'un est-même allé jusqu'à copier/coller le présent fil de discussion. Et je pense que les changements récemment apportés à mon article leur donnent raison. Dans la section contexte, plutôt que de marteler des mots tape-à-l'œil qui font mousser, ou donner des grandes définitions théoriques qui permettent d'avoir l'air 'ach'ment expert, je m'efforçais de présenter ce dont il s'agissait concrètement, dans la vraie vie des vraies gens qui consultent LinuxFr.org. À trop vouloir bien faire, les dernières « corrections » remplacent ces efforts par des non-sens :
En quoi l'accueil des nouveaux serait réductible à l'ergonomie ? En quoi les remerciements de l'équipe du site, lorsque des coquilles sont signalées, relèvent de l'ergonomie ? En quoi le filtrage du spam relève de l'ergonomie ? En quoi un canal IRC relève de l'ergonomie de LinuxFr ? Tout cela n'a plus aucun sens.
Je trouve ce changement cavalier après que j'ai pris le temps d'expliquer dans l'article comme dans les commentaires en quoi la notion d'expérience utilisateur était plus vaste que la notion d'ergonomie et du site web. Des gens trouvent que ça respire le marketing-bullshit-pipeau-3.0 parce que, oulala, une traduction littérale depuis l'anglais ne veut nécessairement rien dire ? Qu'ils lisent l'article. Ils restent convaincus que mon discours témoigne d'une analyse disruptive ancrée dans la modernité du care pour mieux booster le vivre-ensemble bienveillant à l'ère du digital ? Hé bien tant pis, j'assume : l'article est publié en mon nom, et je passerai pour un con à leurs yeux.
Je dis ça sans animosité aucune : je n'ai pas envie de débattre. Sans scrupule, j'use de l'argument d'autorité : puisque j'en suis l'auteur, je demande à ce que la version antérieure de l'article soit rétablie.
J'ai passé un bon moment à me demander pourquoi, à plusieurs reprises, on parlait de « user experience et pas l'inverse ». J'ai du relire tout le fil de discussion pour comprendre que j'avais validé un peu vite la traduction plus haut, désolé…
[^] # Re: Titre en français
Posté par Bruno Michel (site web personnel) . Évalué à 6.
J'ai remis Expérience utilisateur à la place d'ergonomie.
Et merci pour cette dépêche !
[^] # Re: Titre en français
Posté par mjourdan . Évalué à 3.
Merci à toi !
[^] # Re: Titre en français
Posté par Maderios . Évalué à 4.
Suggestion:
[^] # Re: Titre en français
Posté par Davy Defaud . Évalué à 3.
Je comprends tes arguments et tu restes maître de tes écrits. Qu’il en soit ainsi.
[^] # Re: Titre en français
Posté par mjourdan . Évalué à 2.
Merci à toi aussi !
[^] # Re: Titre en français
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 0.
Hop, un superbe exemple : https://linuxfr.org/users/alexandre--2/journaux/le-canada-publie-un-cadriciel-libre-d-analyse-de-maliciels
La connaissance libre : https://zestedesavoir.com
# Améliorons l'expérience utilisateur !
Posté par Leniwce . Évalué à -9.
Hahahaha. Je me suis étouffé avec mon casse-croute tellement j'ai ri, j'en ai encore les larmes aux yeux. Hahahaha
attention chérie ça va moinsser
[^] # Re: Améliorons l'expérience utilisateur !
Posté par Anonyme . Évalué à 1.
bah oui: "Le mots anglais "User experience" ne peut pas être traduit par "expérience utilisateur", c'est un faux-ami"
https://fr.wikipedia.org/wiki/Discussion:Exp%C3%A9rience_utilisateur
[^] # Re: Améliorons l'expérience utilisateur !
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Quoique ça se discute : http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8870544
La connaissance libre : https://zestedesavoir.com
[^] # Re: Améliorons l'expérience utilisateur !
Posté par groumly . Évalué à 2.
Je sais pas chez nous amis québécois, mais en français de chez nous, expérience n’a jamais le sens que les anglais lui donnent dans ce contexte.
Le sens le plus proche qu’on ait, c’est le sens d’experience amoureuse, qui implique un côté formateur (le deuxième sens de http://www.larousse.fr/dictionnaires/francais/expérience/32237) alors que les anglais en ont une version beaucoup pus banale (troisième sens dans https://www.collinsdictionary.com/us/dictionary/english/experience)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Améliorons l'expérience utilisateur !
Posté par romu . Évalué à 3.
Je ne vois pas bien pourquoi. Ce n'est pas parce qu'un terme peut sembler (et être) difficile à comprendre (par exemple parce qu'il englobe une certaine complexité) qu'il n'est pas pertinent pour autant. Et la traduction proposée par Wikipédia ("agrément") est tout autant sujette à caution.
# Pas si long
Posté par Zatalyz (site web personnel) . Évalué à 10.
Le formulaire n'est pas si long. En lisant le paragraphe cité, je m'attendais à devoir prendre quelques heures pour répondre. En fait c'est vraiment vite fait, même en répondant à tout.
Bon courage pour le dépouillement !
[^] # Re: Pas si long
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Je le trouve même court : je pensais à ce qu'on me demande des détails concernant l'ergonomie dans la suite, au-delà des questions vagues-mais-portant-sur-une-partie-précise de la page 1. Mais en fait non.
La connaissance libre : https://zestedesavoir.com
# Commentaire supprimé
Posté par laicnttt . Évalué à -1. Dernière modification le 22 octobre 2017 à 19:33.
Ce commentaire a été supprimé par l’équipe de modération.
# LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Si j'en crois les statistiques du Github, LinuxFR.org semble développé par à peu près une personne (en supposant que ce ne soit pas un artefact de la gestion des commits). C'est un état de fait courant dans le milieu open-source, hélas, quoique je pense un peu surprenant pour un site tel que celui-ci – les compétences dans les membres devraient être légion.
Conséquences : beaucoup d'entrées de suivi non traitées, et si j'en crois une réflexion plus haut, il y a plein de priorités qui ne sont même pas dans ces entrées de suivi.
D'où quelques réflexions :
La connaissance libre : https://zestedesavoir.com
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par claudex . Évalué à 6.
Personnellement, je pense que la complexité de mettre en place une version locale (on est loin d'un simple git clone https://github.com/linuxfrorg/linuxfr.org#install ) rebute un peu les gens.
Je crois que tu te retrouvera avec les même problématique. Et tenter d'adapter un outil existant pour qu'il fasse ce que tu veux et qui n'est pas forcément prévu par cette outil n'est pas plus facile que de développer du code spécifique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 23 octobre 2017 à 11:37.
Je ne suis pas spécialement convaincu par cet argument, pour plusieurs raisons :
Disons qu'en l'état, j'ai l'impression qu'aujourd'hui la décision de développer une plateforme spécifique se fait sur un à priori dont je n'ai pas vu de justification. Sans doute existe-t-il de bonnes raisons de réimplémenter un forum, un outil de suivi, un wiki, mais elles ne me paraissent pas évidentes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
La question ne se pose pas vraiment en ces termes. Quand on a voulu se débarrasser de templeet, j'ai pris la décision de partir sur un développement spécifique plutôt que des logiciels libres existants en 2008 et je pense que c'était le bon choix. J'avais également l'espoir à l'époque que cette base de code spécifique puisse être utilisée par d'autres sites, mais ça ne s'est pas concrétisé.
Depuis, le contexte a changé et si on devait jeter la version actuelle, je militerais pour partir sur des logiciels libres existants plutôt que de tout redévelopper. Mais la version actuelle existe, fonctionne bien et demande peu de maintenance. De l'autre côté, vouloir migrer même vers des outils existants demande un travail très conséquent pour juste arriver au même niveau. Je ne pense pas que l'on ait les ressources pour réussir un tel chantier. Et si on les avait, ça serait sûrement plus efficace de faire évoluer progressivement l'existant que de se lancer dans un gros chantier qui va forcément prendre du temps et dont l'issue est plus incertaine.
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par Obsidian . Évalué à 5.
C'est-à-dire que c'était également les motivations de Templeet, lorsque DLFP a abandonné DaCode. Et Templeet était lui aussi un logiciel libre (et même documenté !), pour les mêmes raisons.
Ça c'est vrai aussi, c'est un plan de migration, et c'est intéressant entre autre pour éviter les régressions […] à condition d'arriver à le faire admettre aux décideurs et aux développeurs de l'équipe au moment où c'est nécessaire.
Mais bon. C'est un peu comme refaire sa maison. C'est très excitant au départ, arrivé à mi-chantier, on se demande pourquoi on s'est embarqué là-dedans et à la fin, il est presque temps de recommencer. En général, on le fait une fois, rarement une deuxième.
Du coup, les années passant, il est probable que si tu transmets à ton tour, un jour, le bébé à une autre équipe, cela marque le début d'un nouveau cycle et que celle-ci en profite pour réécrire une nouvelle fois DLFP en exploitant les technologies du moment.
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 7.
Je confirme que c'est assez compliqué pour un développeur qui n'a jamais touché à rails/ruby, même en utilisation l'installation de ruby par rvm indépendamment de la distribution (et le fichier des Gem pour avoir un environnement de modules externes précis).
J'avais réussi à le mettre en place sur une machine avec Debian Stretch cet été, ce qui m'a permis de proposer le patch d'ajout des norloges dans le nouveau design des tribunes (on peut la voir dans l'espace rédaction ; ça a été fusionné à la main, sans utiliser Github). Seulement, je n'ai plus accès à cette machine depuis.
Le weekend dernier j'ai essayé à nouveau d'installer un environnement de développement sur une autre machine avec Debian Buster et j'ai échoué malgré la réussite sur la première machine: la « simple » configuration de la base de donnée tombe déjà en échec avec des exceptions ruby assez incompréhensible pour un néophyte. Je vais tenter encore une installation sur une machine virtuelle Stretch, mais je pense que ça ne résoudra pas le problème.
Mon avis est que Ruby/Rails bouge trop vite pour ne pas décider d'un environnement plus précis que "stable" et un Gemfile.
PS: Oui, un fichier Docker avait été proposé il y a quelques temps, mais il tombe en erreur également et je pense que c'est à cause de cet environnement trop mouvementé.
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Github n'affiche pas les personnes qui n'ont pas de compte sur github dans ces statistiques. Par exemple, Benoît Sibaud est le deuxième contributeur en nombre de commits (67 commits), mais n'apparaît pas ici. Il y a également quelques autres dépôts git annexes. Mais même en prenant compte cela, je dois être l'auteur de 90% des commits.
Dans les priorités qu'il n'y a pas dans les entrées de suivi, il y a notamment le travail de Mathieu Jourdan (l'auteur de cette dépêche).
J'aimerais bien avoir d'autres développeurs à mes côtés, mais comme tu le fais remarquer plus haut, c'est une situation courante dans le milieu de l'Open Source. Je ne pense pas que ce soit problématique, en tout cas, pas plus que pour d'autres domaines. Côté administration système, il y a aussi des tâches qui prennent du retard (mise à jour debian, cough, cough). Et je ne parle même pas de l'association qui n'a pas tenu d'assemblée générale l'année dernière et ça ne me paraît pas évident que la prochaine arrive avant la fin de l'année. Globalement, la plupart des personnes très impliquées dans le site sont là depuis plus de 10 ans et ont moins de temps à consacrer au site que ça pu l'être par le passé. On aurait bien besoin de nouvelles forces, et si je devais donner une priorité, je dirais animer l'espace de rédaction (ce n'est qu'un avis personnel).
Pour la maintenance, oui. Pour les nouvelles demandes pertinentes, c'est difficile à juger. Il y a pas mal d'entrées dans le suivi qu'il serait bénéfique pour le site d'implémenter mais ça reste du domaine du confort. Je n'ai pas l'impression que ça puisse changer fortement la manière dont les gens voient le site et l'utilisent, mais c'est possible que je rate une entrée de suivi qui pourrait avoir un impact notable pour une partie de notre auditoire. J'ai plutôt l'impression que les demandes viennent des power users, alors que j'aimerais plutôt favoriser l'arrivée de nouveaux lecteurs et surtout contributeurs.
Avec plus de développeurs, on pourrait aller plus vite ;-)
Pour le reste, le travail de Mathieu m'a remotivé à passer un peu plus de temps à développer pour le site. Et je vais faire passer ses demandes en priorité. Ce n'est pas que je considère que les autres demandes ne sont pas intéressantes, c'est juste que je vois dans son travail une attention pour attirer de nouveaux lecteurs et contributeurs sur le site, chose qui me motive tout particulièrement.
Non, ce n'est pas une bonne idée quand on se dit que l'on a trop de travail que de s'en rajouter encore plus. Pour arriver à monter un clone de LinuxFr.org avec une qualité équivalente et en conservant l'historique, il y a un boulot colossal à fournir. J'ai passé plusieurs mois à migrer les contenus de templeet vers la version rails de LinuxFr.org (pas à temps plein) et à l'époque, il n'y avait pas de wiki, de tags, de dépêches collaboratives, etc.
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par ZeroHeure . Évalué à 3.
On n'a pas besoin de connaître Ruby pour certaines choses. En revanche il faut savoir démêler ! ça n'a pas été facile de m'y retrouver l'autre jour pour un simple patch documentaire.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par TutoMaker . Évalué à 10. Dernière modification le 23 octobre 2017 à 15:14.
LinuxFR ne manque pas de gens d'expérience, par contre ils préfèrent passer leur temps libre à troller dans les journaux :D
Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# il y a un truc "chiant"...
Posté par freem . Évalué à 7.
… et c'est les evenements qui sont loin, combines au mode fifo de la page d'accueil.
Que l'on soit un reclus ou simplement habitions (en 4D) trop loin d'un evenement, celui-ci ecrase du contenu plus pertinent, qui a plus d'interet general.
Je ne dis pas qu'il n'en faut pas, au contraire, mais ca serait pratique de pouvoir les filtrer, par exemple avec des points sur une mapemonde, et les gens pourraient ensuite cliquer sur les points (bon, ca, ca semble difficile) et que ca ne remplace pas les depeches/journaux intemporels (sortie de soft, debats, …). J'imagine que le plus simple serait une section pour les contenus localises (dans le temps et l'espace?)?
# Il y a un autre truc "chiant"...
Posté par Kangs . Évalué à 3.
Lors des discussions il est très difficile de voir qui répond à qui, en particulier quand il y a plusieurs réponses.
Certains citent la phrase à la quel ils répondent et ça aide à comprendre, mais la majorité ne le fait pas et le fil de discussion est incompréhensible.
Je n'ai pas de début de solution, mais je trouve ça vraiment "chiant"…
[^] # Re: Il y a un autre truc "chiant"...
Posté par freem . Évalué à 1.
Ce n'est pas toujours possible, ne serait-ce que parce que sur mon tel, il semble m'être impossible de sélectionner du texte hors d'une zone d'édition quand je répond… ça, et les accents qui sont lourds (du coup, à chaque fois, la prévisualisation ressemble à un sapin de Noël, mais j'ai trop la flemme de devoir faire 2s de manipulation pour chaque accent…) dessus.
L'autre cas est quand on répond à un commentaire court dans sa globalité, et non sur un ou deux points précis.
Du coup, la citation en elle-même, même si c'est un outil puissant, n'est ni forcément adaptée ni nécessairement exploitable. Pour le problème que j'ai avec le téléphone, je suppose qu'il «suffirait» d'ajouter un bouton «répondre en citant»?
Sinon, peut-être que l'on pourrait ajouter dans la ligne «Répondre» un indicateur type «message en réponse à […]»? Ça ne me semble toujours pas idéal, et je doute que ça éclaire tant que ça, ceci dit…
[^] # Re: Il y a un autre truc "chiant"...
Posté par Obsidian . Évalué à 4.
Et pourtant, il y a une : c'est le bouton [^] qu'il y a dans le titre de chaque commentaire et qui sert à remonter au commentaire parent (tu peux ensuite utiliser le bouton Back pour revenir à ce que tu lisais). C'est d'ailleurs une suggestion faite dans le suivi il doit y avoir presque une dizaine d'années et qui avait déjà été implémentée du temps de Templeet.
Par contre, la CSS mériterait d'être retravaillée parce que la simple barre verticale à gauche du paragraphe cité est un peu faiblarde. Personnellement, et pas plus tard que ce soir, j'ai ajouté ce qui suit dans « ~/.mozilla/firefox//chrome/userContent.css » :
Ça met un fond gris au bloc cité, ça lui ajoute une ombre et ça réduit légèrement la taille relative de la fonte. Rien que ça, ça facilite beaucoup la lecture des dialogues.
[^] # Re: Il y a un autre truc "chiant"...
Posté par Obsidian . Évalué à 3.
J'ai oublié de dire, pour ceux que cela intéresse, qu'on peut aussi soit mettre en ligne soit carrément uploader ce bout de CSS en bas de cette page : https://linuxfr.org/stylesheet/modifier
Il suffit de copier-coller le bloc présenté et de le faire précéder de la déclaration «
@import url("//linuxfr.org/assets/application.css");» présentée sur ladite page.# NNTP
Posté par pepie34 . Évalué à 3.
Pourquoi ne simplement pas se remettre au NNTP Usenet ?
Avec un site web qui ne serait qu'un client web.
Ça couvrirait quasiment tous les besoins du site et pour le restant ben on étend le protocole ce qui lui ferait du bien car la dernière RFC date de 2006.
Trêve de plaisanterie, mais je me dis quand même que 90% des utilisations des forums/listes de diffusion/réseaux sociaux sont possibles en NNTP et çà serait beaucoup plus efficient.
PS Qui connait une app Android digne de ce nom pour faire du NNTP (et pas pour le téléchargement) ?
[^] # Re: NNTP
Posté par freem . Évalué à 2.
Je ne connais pas Usenet (trop jeune, je suppose) mais à lire rapidement l'article francophone de wikipedia (intéressant pour le coup), je me dis que c'est une sorte d'IRC permanent… je n'en vois du coup pas trop l'intérêt pour un site web, mais effectivement, j'imagine que la plupart des usages seraient réalisables.
Enfin, je ne vois pas trop comment supporter l'édition de contenu (correction de fautes, collaboration autour d'une dépêche, modération… qui sont des fonctionnalités très importantes à mon sens) du fait de la réplication qui expose à des désynchronisation?
Je sais que tu plaisantais, mais je trouve intéressant de chercher à connaître le fonctionnement global des protocoles, et le http(s) everywhere ne m'a jamais paru si pertinent que ça…
[^] # Re: NNTP
Posté par eingousef . Évalué à 3.
Le best protocole ever pour ça c est git
*splash!*
[^] # Re: NNTP
Posté par pepie34 . Évalué à 1.
git over nntp… çà se tente.
Surtout que par dessous git il y a un fs immutable (les dossiers en code hexa) et que nntp en fait c'est juste un protocole de synchro de fichiers aussi de façon immutable (cf l'orgine dans UUCP).
[^] # Re: NNTP
Posté par Tonton Th (Mastodon) . Évalué à 2.
À cause des fufeurs ?
C'est comme ça que fonctionne les forums des utilisateurs de POVray, une interface web que je ne connais que très peu, et un accès standard par NNTP/119 donc utilisable avec un client Usenet classique : Thunderbird, Slrn, toussa…
# Suggestion de présentation
Posté par Richard Medina (site web personnel) . Évalué à 1.
Bonjour;
Je vous suit depuis plusieurs années ainsi que des autres sites en anglais et espagnol, je me permet de vous suggérer quelques modifications de présentation:
Continuez en avant.
Amicalement
Richard
# Main d'oeuvre pour LinuxFr
Posté par sizvix (site web personnel) . Évalué à 2. Dernière modification le 25 octobre 2017 à 09:22.
Développeur web plutôt orienté front-end actuellement ( js pure et léger , j'évite les usines à gaz qui alourdissent tout ) , je peux faire des motifs ou ajouter des fonctionnalités si vous avez besoin , notamment sur du JS ;)
( et si vous voulez intégrer de la VR , des commandes vocales ou autre ;P )
Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote
[^] # Re: Main d'oeuvre pour LinuxFr
Posté par ZeroHeure . Évalué à 3.
Ça tombe bien, les modérateurs ont des tas de petits travaux répétitifs qu'on pourrait faciliter. On fait beaucoup de remplacements, de mise au net. Par exemple oeil s'écrit œil (e dans l'o), les points de suspensions ne sont pas … mais …, des tonnes de gens oublient de précéder les listes par une ligne blanche, il faut mettre des espace insécables pour éviter que la ponctuation passe à la ligne, etc. Je cite comme ça me vient, il y a des corrections plus importantes que d'autres.
Des petites fonctions corrigeant le paragraphe nous seraient utiles. Il faut les ajouter en menu sur l'éditeur Markitup Ce n'est pas difficile et j'avais prévu de m'y atteler, mais tu peux t'en charger plus vite que moi. Évidemment on fournit la liste!
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Main d'oeuvre pour LinuxFr
Posté par claudex . Évalué à 5.
J'aime bien ton exemple des … qui est déjà remplacé automatiquement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 25 octobre 2017 à 11:29.
Un collègue qui passait par là m'a fait une remarque sur le design, qu'il trouve triste et vieux. C'est vrai que j'en ai l'habitude à force de trainer ici (et qu'on est loin d'un developpez.com), mais il y a probablement quelque chose à faire pour rendre le site visuellement plus attractif aux nouveaux venus.
Ça pourrait être aussi l'occasion de retravailler l'ergonomie, avec par exemple des contenus aux lignes moins longues, une police plus lisible (personnellement j'ai un faible pour Merriweather) et sans doute des tas de trucs auxquels je ne pense pas car n'étant pas ergonome.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un coup de polish sur le design ?
Posté par Lutin . Évalué à 3.
Avec les feuilles de style alternatives linuxfr est plutôt joli.
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . Évalué à 2.
D'ailleurs, puisqu'on en parle, est-ce qu'il y a possibilité de joindre des ressources annexes aux CSS alternatives que l'on soumettrait (images, fontes…) et si oui, dans quel dossier faudrait-il les mettre du côté du code (pour ceux qui passent par les pull requests) et via quelle URL seraient-elle accessibles ensuite ? (nécessaire pour la CSS elle-même).
[^] # Re: Un coup de polish sur le design ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
On utilise sass pour les CSS du site. Ça s'écrit comme de la CSS mais ça permet d'importer quelques styles communs (ceux pour la coloration syntaxique du code dans les contenus et commentaires par exemple). Voici un exemple d'utilisation d'une image : https://github.com/linuxfrorg/linuxfr.org/blob/master/app/assets/stylesheets/contrib/kaiska-new.css.scss#L132 et l'image se trouve dans ce répertoire : https://github.com/linuxfrorg/linuxfr.org/tree/master/public/images/contrib/kaiska.
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . Évalué à 2.
C'est noté. Merci pour les indications !
[^] # Re: Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Sans doute qu'avec les feuille de style alternatives ont trouve du plus joli, mais je pense à tous les visiteurs qui découvrent le site.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . Évalué à 2.
C'est vrai qu'il y a beaucoup de choses sympa dans les Google Fonts et que ça permet de décorer un peu le web. Celle-ci est belle, en effet, et je crois que je vais la garder sous le coude. Cela dit, elle est assez proche (au moins sur un rendu papier) de Libération, qui est déjà largement répandue sur les distribs. J'ai aussi un faible pour Linux Libertine, que j'avais impliquée dans Springtime sous Templeet, juste avant le passage à Ruby.
[^] # Re: Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
L'avantage des polices web, c'est qu'on a pas à se demander si elles sont disponibles sur tel ou tel OS. Malgré son nom, je pense que LinuxFR est visualisé depuis autre chose que des distrib' Linux, et là aussi le rendu devrait être bon.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . Évalué à 3.
Oui mais quand on soumet une CSS, on peut en fait ajouter le fichier de la fonte elle-même aux ressources, au même titre que les images associées. On peut donc, a priori, utiliser n'importe quelle fonte, même si elle très exotique. En principe, elle n'est chargée qu'une seule fois par le navigateur. Si, en plus, elle est déjà sur la distrib', c'est tout bénéf' pour le lecteur.
[^] # Re: Un coup de polish sur le design ?
Posté par Wrap . Évalué à 1. Dernière modification le 27 octobre 2017 à 00:30.
Je ne sais pas à quoi tu penses quand tu dis "Un coup de polish sur le design" mais si c'est pour transformer le site en un truc super lent avec des animations de partout … Je préfère le design triste et vieux. En plus, même si les couleurs actuelles ne sont pas les plus jolie du monde, je les trouvent plutôt reposantes pour les yeux.
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . Évalué à 3.
En fait, l'avantage, c'est 99,9% de la chose passeraient par une simple CSS. Nul besoin de scripts ou d'extensions particulières. Donc aucun ralentissement. Et si l'on veut quand même des animations flashy, CSS3 permet déjà d'en faire énormément avec
transitionettransform.Ce qui est bien, c'est que sur DLFP, les utilisateurs sont traditionnellement incités à le faire et il existe des facilités pour mettre facilement en place ses créations avec le lien changer de style, à gauche dans la boîte principale.
[^] # Re: Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Il y a sans doute un juste milieu entre « triste, vieillot et peu avenant » et « mettre des animations partout ». Un concept du genre « accueillant et lisible », sans doute.
La connaissance libre : https://zestedesavoir.com
# Journal VS depeche
Posté par MTux . Évalué à 2.
En effet… je n'ai jamais compris la différence entre les deux et je ne comprends pas pourquoi ils existent. Pourquoi n'y aurait-il pas une seule page "news" ou "articles" ?
[^] # Re: Journal VS depeche
Posté par gasche . Évalué à 7.
Pour moi une dépêche c'est sérieux, c'est sur la page d'accueil, il faut que ça soit bien léché et accessible au plus grand nombre (et en plus les autres gens viennent mettre leur grain de sel dans le texte, ce qui est parfois bien et parfois casse-pieds), alors qu'un journal c'est un espace d'expression plus libre et plus brute, on peut mettre des trucs dessus et voir si ça colle—ou pas. Je trouve les deux très différents, du point de vue des auteurs comme de celui des lecteurs, et je pense que mélanger les deux notions serait une perte.
[^] # Re: Journal VS depeche
Posté par Obsidian . Évalué à 4.
Les journaux, ici, sont surtout des « journaux de bord » ou des « journaux intimes (sauf qu'ils ne sont pas intimes) » et se traduisent en anglais par « log », soit en fait « blog » puisqu'ils sont sur le web.
Les journaux sont donc en fait les blogs personnels des membres, sauf que les derniers billets sont référencés par un lien qui se trouve directement dans la barre de haut de page, et cela marche parce que le public de linuxfr.org est en grande partie composé d'habitués de longue date.
De la même façon, les dépêches seraient des « news », mais ici, on est bien sur linux fr.org ;)
Les principales différences sont que d'une part, tout le monde peut participer à la rédaction d'une dépêche, qui généralement rédigée à plusieurs dans l'espace de rédaction alors qu'un blog est privé par nature, et que d'autre part, un journal soumis est immédiatement publié (comme un commentaire), alors qu'une dépêche est soumise à approbation finale de la modération. De fait, les dépêches sont en fait publiées en page d'accueil au nom du site (même si elles sont quand même créditées à leur auteur), alors que les billets de blog, d'un point de vue moral, n'engagent que leur auteur.
Évidemment, d'un point de vue légal, les unes et les autres doivent être modérés de la même façon et, de toutes façons, on rend toujours crédit à l'auteur d'un papier, quel qu'il soit. Mais c'est comparable aux articles d'un journal papier écrits par les membres de sa rédaction, par rapport aux petites annonces qui sont publiées dans ses pages.
Enfin, dans cet esprit, une dépêche se soit d'avoir un intérêt pour tout le lectorat du site, alors qu'un
billet de blogjournal, lui, peut parler de tout ce qui intéresse son auteur, tant que cela ne devient pas du spam caractérisé et qu'il n'y a pas flood.Comme il est très difficile de produire en continu des dépêches valides sur l'actualité sur un site communautaire et sans avoir de chroniqueur attitré, alors les journaux sont ici mis en évidence car on a la chance qu'ils soient de bonne qualité par rapport à certains autres sites (et ce, parce que les gens ont l'habitude de les utiliser de longue date). Un billet de blog particulièrement intéressant et bien écrit peut ensuite, éventuellement, être promue en dépêche.
# 10 jours pour répondre, même pas ?
Posté par Thomas Debesse (site web personnel) . Évalué à 4. Dernière modification le 31 octobre 2017 à 14:15.
J’avais commencé à répondre à l’enquête il y a quelques jours, mais débordé par le travail j’avais dû remettre à quelques jours de plus. Ayant le temps aujourd’hui je décide de m’y remettre et je découvre avec stupeur que l’enquête est close, 10 jours c’est super court non ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: 10 jours pour répondre, même pas ?
Posté par mjourdan . Évalué à 2.
Ça ne m'a pas semblé si court que cela, étant donné la forte participation au lancement de l'enquête (environ 200 réponses sur les 2 premiers jours) qui s'est vite tassée (une quarantaine de réponses supplémentaire sur les 5 jours suivants). C'est une quantité de réponses bien suffisante au regard de notre objectif. Désolé pour la frustration…
Au passage, merci au modérateur d'avoir indiqué dans l'article que l'enquête était close !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.