Suivi — Commentaires Amélioration de l'édition des commentaires

#710 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel.
Étiquettes : aucune
9
28
nov.
2011

Suite à l'intégration du patch de gasche, que je juge un peu hâtive puisqu'il n'y a pas eu de consensus publique (manifestement) au sujet des modalités de cette fonctionnalité certes intéressante, j'aimerais proposer des améliorations qui paraissent évidentes pour éviter les abus.

Pour moi, il y a deux solutions assez opposées représentées par deux ensemble d'améliorations à apporter :

Historique des commentaires

L'objectif est de permettre l'édition illimitée dans le temps, mais de ne pas perdre d'informations pour que les discussions puissent rester cohérentes.

Ça s'implémente de deux manières :

  • Soit chaque commentaire a, à l'instar des pages de wiki, un historique de révisions, et tout un chacun a la possibilité de lire l'historique des modifications, les diffs, etc.
  • Soit on conserve uniquement le texte d'origine et la dernière version modifiée. Ça a l'avantage de moins chambouler le schéma de base de données et d'être moins complexe, c'est peut-être suffisant, même si une version intermédiaire peut donc disparaitre à tout moment.

Limitation dans le temps

Ici, pour conserver la cohérence des discussions sans garder l'historique des modifications, on peut :

  • Empêcher l'édition d'un commentaire auquel quelqu'un a répondu ;
  • Empêche l'édition d'un commentaire au bout d'un laps de temps assez court (typiquement dix minutes).

L'idée est que si l'objectif de l'édition des commentaires est principalement pour corriger des fautes d'orthographe, ça devrait suffire.

D'ailleurs une autre idée d'amélioration, c'est d'exiger qu'un commentaire modifié ait 50% de texte similaire avec le commentaire original, pour éviter une réécriture complète d'un commentaire « Merci patrick_g pour ta dépêche t'es mon dieu. » en « Mort au pape. ».

  • # Impératif

    Posté par  (site web personnel) . Évalué à 4 (+0/-0).

    Toutes ces propositions sont impérative, transparence oblige.

    Autre truc : un user doit pouvoir soumettre une correction pour tout type de contenu, le posteur reçoit alors un diff qu'il peut choisir d'appliquer.

    • [^] # Re: Impératif

      Posté par  (site web personnel) . Évalué à 7 (+0/-0).

      Je serai assez favorable à la solution de type "on conserve uniquement le texte d'origine et la dernière version modifiée". Cela me semble un bon compromis puisque ça permet de corriger les fautes d'orthographes, d'avoir la visibilité sur le post d'origine sans avoir à garder tout l'historique des diffs.
      Un bon compromis sans doute.

  • # Typographie

    Posté par  . Évalué à 2 (+0/-0).

    À noter également (c'est du détail qui ne devrait pas appeler à polémique) :

    Évalué à 3 . Dernière modification : le 28/11/11 à 17:01

    Derrière le "Évalué à n", il y a un espace en trop. De plus, la fin de la ligne ne contient plus d'espace.

    J'imagine que la correction ne devrait pas être trop difficile...

  • # Fait

    Posté par  (site web personnel) . Évalué à 4 (+0/-0).

    J'ai pris l'option « limitation dans le temps ». Cf https://github.com/nono/linuxfr.org/commit/5cd872853507edde50a678336c9436af09cdb09e

  • # Coder pour des chimères

    Posté par  . Évalué à 3 (+0/-0). Dernière modification le 29 novembre 2011 à 07:28.

    Je ne comprends pas l'intérêt de restreindre une fonctionnalité utile en raisons d'abus imaginaires. Est-ce que l'un de vous a déjà observé un comportement abusif tel que décrié ici ?

    Pour ma part il m'arrive relativement fréquemment de relire un commentaire après qu'on y ait répondu (en vrai c'est souvent le moment où j'ai le plus tendance à le relire) et cette restriction limite donc l'usage de l'édition.

    Elle ne permet pas non plus certains modes d'utilisation très utiles de l'édition, tels que : "proposez moi des liens vers 'truc' en réponse à mon commentaire, j'éditerais le commentaire principal pour montrer une liste bien structurée des propositions vérifiant 'tel critère'".

    Je pense qu'avant d'ajouter des restrictions arbitraires, il faudrait s'assurer que les hypothèses conduisant à leur mise en place sont belles et bien vérifiées. J'attends vos liens vers un commentaire édité abusivement.

    PS: sur les forums n'ayant pas d'historique, quand quelqu'un dit quelque chose de limite, il est souvent quoté par d'autres gens qui lui répondent sur ce point. Ça limite beaucoup la possibilité d'éditer pour cacher la chose.

    • [^] # Re: Coder pour des chimères

      Posté par  . Évalué à 5 (+0/-0).

      Elle ne permet pas non plus certains modes d'utilisation très utiles de l'édition, tels que : "proposez moi des liens vers 'truc' en réponse à mon commentaire, j'éditerais le commentaire principal pour montrer une liste bien structurée des propositions vérifiant 'tel critère'".

      Je ne saisi pas l'intérêt, autant faire un commentaire à la fin qui regroupe ça, c'est plus clair pour tout le monde. Pourquoi vouloir absolument attendre qu'il y ait des problèmes pour lutter contre alors qu'il n'y a pas vraiment de bonne raison pour laisser l'édition libre. Si c'est pour modifier les commentaires une fois que tout le monde les as déjà lu, ça ne sert plus à rien.

      « 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: Coder pour des chimères

        Posté par  . Évalué à 3 (+0/-0). Dernière modification le 29 novembre 2011 à 09:44.

        Je ne saisi pas l'intérêt, autant faire un commentaire à la fin qui regroupe ça, c'est plus clair pour tout le monde.

        L'intérêt c'est de mettre à jour régulièrement pour que les nouvelles personnes sur le thread aient accès à un condensé. Dans mon exemple ça permet par exemple aux gens de savoir facilement si le lien auxquels ils pensaient a déjà été posté.

        La notion de "à la fin" n'a pas de sens sur une discussion internet où des gens peuvent rajouter un message à tout moment. Techniquement je crois que sur LinuxFR on ne peut pas commenter le vieux contenu (ce que je trouve assez discutable comme choix mais c'est un autre débat), mais ton idée d'attendre de s'assurer que plus personne ne va participer à une discussion pour aller poster un récapitulatif est assez curieuse : à qui servira-t-il ?

        Pourquoi vouloir absolument attendre qu'il y ait des problèmes pour lutter contre alors qu'il n'y a pas vraiment de bonne raison pour laisser l'édition libre.

        Pourquoi attendre qu'il y ait des problèmes ? Parce qu'avant de s'embêter à faire des changements dans le code, il faut s'assurer que les besoins sont réels. Personnellement je doute qu'ils le soient : tous les sites de discussion que je fréquente à part LinuxFR permettent l'édition des commentaire, à ma connaissance aucun d'entre eux n'implémente d'historique compliqué, et je n'ai jamais rencontré de situation où ce soit vraiment problématique¹.

        Il n'y a pas de bonne raison ? Bien sûr qu'il y a une bonne raison. C'est la façon la plus pratique de faire (on peut corriger quand on veut). En plus ça me fait plaisir.

        ¹: un jour un gars est parti d'un site en claquant la porte et a balancé un script web pour effacer tous ses commentaires en les éditant avec un message vide. Je n'ai vu ça qu'une seule fois, et sur le moment je me suis plutôt dit "Bon débarras" (indépendamment du fait qu'il était convaincu qu'en raison de la loi sur les œuvres de l'esprit blabla on n'avait pas le droit de l'empêcher de retirer ses commentaires; je ne pense pas que ce soit légalement valide mais moi s'il veut supprimer son propre contenu, du moment que tout le monde n'est pas caractériel à ce point...).

        Je trouve ça assez fort de café quand même, je me fatigue à implémenter une fonctionnalité que je trouve importante et, sous prétexte que vous imaginez tous les abus possibles et imaginables, on se retrouve à la mutiler en la rendant nettement moins utile.

        La meilleure solution parmi les solutions proposées est clairement d'avoir un historique complet des commentaires. Je pense que nous sommes d'accord là-dessus et ça ne me dérangerait pas du tout que ce soit mis en place. Mais je pense que la solution précédente (édition libre sans historique) est meilleure que la solution actuelle (édition bridée de façon arbitraire).

        Je pense que ça en dit long sur la communauté de LinuxFR : je fait des efforts pour que soit rendue disponible une fonctionnalité permettant d'améliorer le contenu du site, en permettant aux gens de corriger leurs fautes, de changer leur formulation etc., et tout ce que les gens y voient c'est les possibilités d'en abuser pour emmerder les autres participants...

        Edit: et zut aux gens qui ont moinssé mon premier post.

        • [^] # Re: Coder pour des chimères

          Posté par  . Évalué à 3 (+0/-0).

          T'être emmerdé à avoir développé un patch est très bien, mais ce n'est pas pour ça qu'il a à être intégré tel quel. Sinon je n'ai qu'à envoyer un patch pour empêcher Oumph< de détecter les multis, ça m'arrangerait.

          Que tu considères l'édition des commentaires comme une bonne chose sur d'autres sites parce qu'ils ont choisi ce fonctionnement, pourquoi pas, mais sur DLFP le mode de fonctionnement a toujours été que les contenus soient statiques une fois publiés. Le fait qu'il ne soit pas possible de poster de commentaires sur les contenus plus vieux de trois mois va dans ce sens également.

          Donc pourquoi pas pour l'édition de commentaires cinq minutes pour corriger des fautes, mais un changement plus profond est, pour moi, une réorientation de DLFP qui perd une restriction que je voyais comme un atout du site.

          Si tu veux avoir des espaces de discussion où tout le monde peut éditer les commentaires de tout le monde à tout moment, va sur Wikipédia.

          • [^] # Re: Coder pour des chimères

            Posté par  . Évalué à 2 (+0/-0).

            Je suis d'accord sur le fait qu'un code n'a pas nécessairement à être adopté tel quel. Ce que je dis ce n'est pas qu'il doit être adopté par principe, mais que le comportement qu'il mettait en place était meilleur que celui qui a été ajouté ensuite.

            Que tu considères l'édition des commentaires comme une bonne chose sur d'autres sites parce qu'ils ont choisi ce fonctionnement, pourquoi pas, mais sur DLFP le mode de fonctionnement a toujours été que les contenus soient statiques une fois publiés.

            Oui, mais pourquoi ? Ce n'était pas juste une limitation technique du site ? Je ne vois pas d'argument de fond.

            Et dans ce cas, comment pouvez-vous être si sûrs qu'il va y avoir plein d'abus ?

        • [^] # Re: Coder pour des chimères

          Posté par  (site web personnel, Mastodon) . Évalué à 4 (+0/-0).

          Il n'y a pas de bonne raison ? Bien sûr qu'il y a une bonne raison. C'est la façon la plus pratique de faire (on peut corriger quand on veut). En plus ça me fait plaisir.

          Comme bonnes raisons, j'ai trouvé mieux. Entre un argument d'autorité (avec lequel tout le monde n'est pas forcément d'accord, loin de là) et un argument suggestif, je suis très loin d'être convaincu.

          Contrairement à beaucoup d'autres, tu as le mérite de ne pas avoir juste gueulé, mais tu as pris les choses en main et tu as proposé un patch pour implémenter ta demande. C'est tout à ton honneur. Celui-ci a été intégré quasiment immédiatement, en l'adaptant un peu à la culture et la philosophie générale du site. On ne change pas en qqs heures une fonctionnalité d'un site et d'une communauté qui, quoi qu'on en dise, fonctionne plutôt pas trop mal actuellement. On intègre et teste par petits bouts et on voit ce que cela donne.
          Quand il a réécrit le site en Rails, je pense que NoNo avait plein d'idées et de trucs qu'il aurait voulu changer. mais au final, il a essayé de rester dans ce qui était l'esprit de LinuxFr.org avant.

          • [^] # Re: Coder pour des chimères

            Posté par  . Évalué à 3 (+0/-0).

            Je peux reformuler l'argument "pouvoir corriger quand on veut est la façon la plus pratique de faire" ainsi : le principe d'un site de discussion est de supposer que quand les membres créent du contenu, c'est positif, ils apportent quelque chose.

            Permettre d'éditer leur permet de créer du contenu de façon un peu plus incrémentale; il y a des gens qui n'ont pas besoin de cette flexibilité supérieure, ils écrivent une fois, se relisent, et n'ont jamais envie de retoucher ensuite, mais il y a aussi des gens que ça aide, car ils pensent après-coup à des façon de simplifier, mieux structure leur propos (sans changer le sens de l'ensemble pour ne pas perturber la conversation; c'est du bon sens).

            Si tu supposes que laisser les gens apporter leur contenu (dans les commentaires) est positif, il me semble naturel de considérer que les laisser en améliorer la forme à volonté est positif aussi.

            Celui-ci a été intégré quasiment immédiatement, en l'adaptant un peu à la culture et la philosophie générale du site.

            Je te pose la même question qu'à 'moules' : en quoi le fait de ne pas pouvoir éditer ferait partie de la "culture" et de "la philosophie générale" d'un site, plutôt qu'une simple limitation technique qui n'a jamais été levée par manque de temps ou de motivation ?

            Je ne comprends pas l'argument "c'est bien parce que c'est vieux", "c'est bien parce qu'on a toujours fait comme ça". En quoi est-ce bien de ne pas pouvoir éditer ses messages ?

            Par ailleurs je trouve que ta lecture de la situation est un peu simpliste : le changement n'a pas été "intégré en adaptant ...". Il a été intégré, et ensuite des gens sont venus râler pour demander de l'adapter pour des raisons qui ne me semblent pas tenir debout : on parle de risques d'abus, mais comme je l'ai dit il n'y a eu aucun abus constaté, et d'ailleurs vous passez votre temps à me dire que cette fonctionnalité n'a jamais été disponible, comment alors pouvez-vous savoir à l'avance qu'il y aura des abus ?

            Contrairement à beaucoup d'autres, tu as le mérite de ne pas avoir juste gueulé.

            Rassure-toi, j'ai commencé par juste gueuler :)

    • [^] # Re: Coder pour des chimères

      Posté par  (site web personnel, Mastodon) . Évalué à 4 (+0/-0).

      Elle ne permet pas non plus certains modes d'utilisation très utiles de l'édition, tels que : "proposez moi des liens vers 'truc' en réponse à mon commentaire, j'éditerais le commentaire principal pour montrer une liste bien structurée des propositions vérifiant 'tel critère'".

      On va peut-être éviter les "TopiksUniksALaCon", non ?

      D'ailleurs, si le besoin de synthétiser le contenu de plusieurs posts, commentaires, discussions est si important, utile, pressant, etc. il y a le wiki pour ça (réclamé à corps et à cris pas beaucoup de monde). Eh oui, contrairement à d'autres sites, LinuxFr.org propose un wiki librement éditable par tous dans le temps ! Chaque site a sa propre philosophie et sa propre. Pas la peine d'essayer d'appliquer/calquer le fonctionnement d'autres sites ici, ca n'a pas de sens àmha.

  • # Discussion en liste chaînée : par là s'il vous plaît

    Posté par  . Évalué à 4 (+0/-0).

    Après un petit intermède publicitaire, la discussion reprend dans le journal créé à cet effet. Merci pour votre participation !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.