Suivi — Rédaction Réduire la liste de dépêche en cours de rédactions

#1958 Posté par  (site web personnel, Mastodon) . État de l’entrée : ouverte. Assigné à Adrien Dorsaz. Licence CC By‑SA.
Étiquettes :
3
11
déc.
2020

Suite au journal de tisaac pour faire un peu de ménage en rédaction, je me suis dit que l’on pouvait aussi techniquement cacher par défaut les dépêches « vieillissantes ».


Mise à jour du 14.12.2020

À la place de cette artifice où je proposais de "cacher" certaines dépêches (ci-après), j'ai vu que LinuxFr était déjà prêt pour faire une relance et un nettoyage automatique, comme décrit dans ce fil de discussion.


Je propose de couper en deux la liste des dépêches « en cours de rédaction ».
Arbitrairement, je propose de cacher les dépêches qui n’ont pas été modifiées depuis 3 mois.

Pour cacher, je pensais utiliser la balise HTML5 details qui permet de cacher par défaut du contenu et qui est reconnu par beaucoup de navigateurs. L’avantage, est que si le navigateur ne connaît pas cette balise, le contenu est simplement affiché (donc, on est dans le même état que maintenant).

Voilà un aperçu de ce que ça pourrait donner (le PR est ouvert sur Github):

Liste des dépêches avec quelques-unes cachées

Cette solution technique ne traite bien sûr pas le problème de fond présenté par le journal.

Par contre, elle permet d’éviter un trop grand bruit pour le nouveau rédacteur motivé à participer.

  • # Alternative

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

    Une alternative sans doute plus compliquer à mettre en oeuvre serait d'avoir trois catégories :

    1. dépêche en cours de rédaction
    2. dépêche à adopter
    3. dépêche en cours de modération

    avec un passage automatique de la catégorie 1 à la catégorie 2 après x mois de non-activité.

    Cette alternative est moins efficace pour réduire le bruit. Elle permet par contre d'expliciter qu'après x mois de non-activité, une dépêche peut être adopter par quelqu'un d'autre. On peut/doit dans ce cas-là prévoir un petit texte expliquant le concept et la marche à suivre pour adopter (annoncer dans la tribune de la dépêche que l'on souhaite adopter la dépêche ?)

    Ceci est une alternative. J'ai pas d'avis clair si c'est mieux ou moins bien que la proposition d'Adrien.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Alternative

      Posté par  (site web personnel, Mastodon) . Évalué à 4 (+0/-0). Dernière modification le 12 décembre 2020 à 09:24.

      Une alternative sans doute plus compliquer à mettre en oeuvre serait d'avoir trois catégories :

      dépêche en cours de rédaction
      dépêche à adopter
      dépêche en cours de modération

      avec un passage automatique de la catégorie 1 à la catégorie 2 après x mois de non-activité.

      Ça tombe bien, c’est exactement le système que j'ai proposé dans le PR: les dépêches « cachées par défaut » sont les dépêches à adopter et elles passent là après 3 mois de non-activité.

      Tu as raison, il vaut mieux donner des noms un peu plus clairs, j’ai donc ajusté le titre en « 9 dépêches à adopter »:

      catégorie dépêches à adopter fermées

      Et quand on ouvre la catégorie, j’ai ajouté une notice pour expliquer ce que veut dire « à adopter » et en dessous un texte pour expliquer comment procéder:

      catégorie dépêches à adopter ouverte

      Au cas où les images ne passent pas, j'ai mis les textes suivant:

      Les dépêches suivantes n’ont plus d’activités depuis plus de 3 mois et peuvent être adoptées pour être finalisées et publiées par d’autres rédacteurs.

      Pour adopter une dépêche, vous pouvez demander dans la tribune de rédaction de devenir l’auteur de la dépêche. Ainsi, l’équipe de modération vous donnera le rôle d’auteur de la dépêche et vous pourrez terminer le processus de publication.

      Est-ce que les textes te plaisent ?

      • [^] # Re: Alternative

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

        Oh, et si tu veux tester en direct, tu peux aller sur mon site de test.

        • [^] # Re: Alternative

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

          Ok. Il n'y a plus d'alternatives. Il n'y a qu'une proposition :-)

          3 mois c'est peut-être court. Mais perso, je n'ai pas de religion dessus.

          Les textes me paraissent bien a priori.

          En complément, il faudrait peut-être prévoir d'envoyer un mail au rédacteur initial pour le prévenir que sa dépêche est passée au statut d'adoptable. Soit automatiquement, soit à faire par l'équipe d'animation de l'espace rédaction.

          Surtout, ne pas tout prendre au sérieux !

          • [^] # Re: Alternative

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

            3 mois c'est peut-être court. Mais perso, je n'ai pas de religion dessus.

            En regardant la liste actuelle, je trouvais que 3 mois ça faisait déjà pas mal de dépêches actuellement actives: toutes les dépêches mises à jour après le 12 septembre restent affichées et du coup ça fait jusqu'à la dépêche "Python pour Noël 2020 — partie 7 — Environnements virtuels" actuellement.

            En complément, il faudrait peut-être prévoir d'envoyer un mail au rédacteur initial pour le prévenir que sa dépêche est passée au statut d'adoptable. Soit automatiquement, soit à faire par l'équipe d'animation de l'espace rédaction.

            En fait, il n'y a pas vraiment de changement d'état, le système est très simple pour l'instant: si la dernière mise à jour date de plus de 3 mois, on cache la dépêche. Ça veut dire que, dès que quelqu'un fait la moindre modification, elle repasse en "dépêche active".

            On pourrait imaginer ajouter une tâche journalière qui envoie un mail, mais j'avoue que je n'ai pas la motivation de faire 😅

            En fait, je ne m'y connais pas trop en Ruby on Rails, du coup, ça me demanderait pas mal d'investissement personnellement.

  • # Qui des anciens et de leur motivation ?

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

    • d'abord c'est agréable de voir des propositions d'évolution,, merci
    • ceux qui font font plus que ceux qui commentent juste
    • malgré tout, ceci étant dit, par ailleurs, nonobstant, cependant, est-ce que ça ne cache pas juste la misère sous le tapis : certes c'est mieux pour les nouveaux, mais c'est probablement moins bien pour les anciens qui ont contribué aux dépêches cachées sous le tapis ? Le souci de fond, c'est qu'il y a des dépêches qui végètent en rédaction pour de bonnes (sortie d'un logiciel différé, auteur initial porté disparu et personne ne l'a encore remplacé, etc.) ou de mauvaises raisons (écriture en cours d'un mémoire de 800 pages exhaustifs sur un sujet, oh un papillon si je commençais une autre dépêche sur un autre sujet, etc.)
    • comment finaliser les dépêches qui traînent en rédaction ? Plus d'humain avec plus d'animateurs de rédaction pour veiller à l'état de fraîcheur des dépêches ? Plus de technique pour aider avec des relances/rappels/alertes ?
    • [^] # Re: Qui des anciens et de leur motivation ?

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

      Tout à fait, le but de cette proposition est juste d’éviter d’apeurer les nouveaux venus.

      Pour le problème de fond, je pense que le système des animateurs prévu était bien fait. Je me souviens d’une époque où Nÿco (je crois) faisait régulièrement des relances sur les dépêches qui tombaient dans les Abymes de l’oubli avec un petit délai genre « si non suppression dans 1 semaine ».

      Peut-être que la vraie solution est de rendre ça automatique en expliquant que l’espace de rédaction est un espace commun où le ménage est fait régulièrement par un script de relance et un de nettoyage.

      Comme je disais plus haut, malheureusement, ça me demanderait pas mal d’investissement parce que je ne connais pas bien Ruby On Rails et je ne sais pas comment y ajouter des crons. Si je me souviens bien, il y a déjà un système en place pour recalculer le karma régulièrement, je pourrais m’en inspirer.

      • [^] # Re: Qui des anciens et de leur motivation ?

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

        Oh, tout est déjà en place, ça doit être faisable en fait.

        On a le système de cron dans lib/tasks/linuxfr.rake et le système d'envoi de mail dans app/mailers/news_notifications.rb.

        Je vais faire quelques tests ces prochains jours 😀

        • [^] # Re: Qui des anciens et de leur motivation ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 12 décembre 2020 à 14:01.

          Je viens de voir que l'on a des template de réponses pour les dépêches refusées et il y en a déjà une pour "Dépêche abandonnée" avec ce texte:

          La dépêche que vous avez proposée est restée très longtemps dans l’espace de rédaction collaboratif sans aucune modification alors qu’elle n’est pas terminée.

          Considérant ce contenu abandonné, et pour conserver un certain dynamisme dans l’espace de rédaction collaboratif, nous préférons le refuser.

          Rien ne vous empêche de le proposer à nouveau si besoin.

          Je vais l'utiliser pour le cron de "nettoyage" et je peux préparer un autre template pour le cron de "relance avant nettoyage".

          • [^] # Re: Qui des anciens et de leur motivation ?

            Posté par  (site web personnel, Mastodon) . Évalué à 5 (+0/-0). Dernière modification le 12 décembre 2020 à 20:01.

            Voilà, si ça vous dit, j'ai préparé un commit pour ajouter 2 tâches cron exécutées quotidiennement:

            1. Une première tâche qui repère quand un brouillon de dépêche n'a pas été mise à jour depuis 5 mois et 2 semaines
              • Cette tâche envoie un email de relance comme les animateurs peuvent le faire et ajoute le message: La dépêche semble abandonnée et sera automatiquement supprimée dans 2 semaines si aucune modification n'y est apportée.
              • Ce même message est publié sur la tribune de la dépêche
            2. Une seconde tâche qui prend tous les brouillons de dépêche dont la dernière modification remonte à plus de 6 mois
              • Elle passe la dépêche de l'état "brouillon" à "supprimé"
              • Elle envoie un email à l'auteur (et, en copie, l'équipe de modération) expliquant que la suppression est automatique et joint le contenu de la dépêche

            Si vous pensez que ça peut être utile, dites-le moi et je ferai un Pull Request sur Github.

            Je pense que si on a ce système automatique, il n'y a plus besoin de mon autre proposition de "cacher" les vieux contenus, puisqu'il ne restera que les "frais" (moins de 6 mois d'abandon).

    • [^] # Re: Qui des anciens et de leur motivation ?

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

      comment finaliser les dépêches qui traînent en rédaction ? Plus d'humain avec plus d'animateurs de rédaction pour veiller à l'état de fraîcheur des dépêches ? Plus de technique pour aider avec des relances/rappels/alertes ?

      Suite au récent journal Les dernières nouvelles du nettoyage de l'espace de rédaction, je continue de penser qu'il vaut mieux compter sur les moyens techniques pour garder un espace de rédaction conviviale à tous.

      En effet, dans ce journal, tisaac montre bien qu'il y a quand même pas mal de sentiments en jeu pour les animateurs (traumatisme, désespérant…). Alors que pour un robot, c'est fait sans appréhension.

      Je ne pense pas qu'il y ait besoin de tant de sentiments, car l'auteur qui a lancé la dépêche l'a certainement oublié et est passé à autre chose. Le robot enverra un rappel quelques jours avant la suppression et si aucun n'espoir n'est donné à la dépêche, elle sera supprimée (enfin "cachée dans la base de donnée", rien n'est vraiment supprimé sur LinuxFr).

      Un autre arguement est que pas mal d'autres communautés font le même genre de système automatique: je vois de plus en plus souvent des robots fermer automatiquement des Pull Request sur Github après x jours (les animateurs sont un peu les "mainteneur de l'espace de rédaction") ou encore des Discourse qui ferment les commentaires après 15 jours sans activité (là, il y a bien la communauté qui anime).

      Dans le journal on voit également:

      En dehors des valeurs sûres, il n’y a que deux dépêches qui ont été entamées avant le 1er janvier 2021. Seules trois dépêches n’ont pas donné signe de vie sur les 6 derniers mois. Je ne vais pas dire que les autres sont toutes hyper actives mais bon, en termes de sédimentation, c’est vachement moins important que quand j’ai commencé mon œuvre.

      Le robot aurait donc supprimer 5 dépêches si on le règle pour 6 mois d'inactivités.

      Ça ne sera pas non plus une hécatombe ;-)

      En effet, quelqu’un a osé indiquer au fronton d’une dépêche dans l’espace de rédaction : Merci de ne pas contribuer ni rien traduire. Pour l'instant, ce sont mes notes et points de repères dans des docs. J’en vois dans le fond déjà chercher des excuses à ce malheureux en avançant que cela peut être utile pour construire dans un premier temps une structure un peu correcte de la dépêche.

      Là, je trouve que c'est un abus de l'espace publique proposé pour la communauté LinuxFr, on pourrait même imaginer une intervention à la main pour supprimer cette dépêche.

      Pour ça, il y l'autre entrée de suivi qui propose d'améliorer l'interface pour les animateurs.

  • # Six mois plus tard

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

    Avec six mois de recul, je me dis que le mieux est quand même d’avoir une équipe d’animation de l’espace de rédaction active plutôt qu’un système automatique. Chaque cas est presque unique et est difficilement inscriptible dans des règles générales.

    Par contre, je pense que c’est une règle quasi-générale, il faut supprimer les dépêches qui n’ont plus d’activité lors des derniers 12 mois. Vu que les cas sont en fait rare, pas besoin de l’automatiser si ce n’est qu’on a parfois des scrupules à supprimer des dépêches. Comme, vous l’aurez remarqué, LinuxFR parle beaucoup d’informatique, une dépêche qui a trainé plus de 12 mois dans l’espace de rédaction nécessite souvent un gros travail d’actualisation pour les références aux versions actuelles de logiciels ainsi que pour les liens qui n’existent plus toujours ou plus souvent qui ne sont plus les plus pertinents.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Six mois plus tard

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

      Ça m'est arrivé quelquefois de contribuer un peu à une dépêche pour essayer de la faire avancer, et franchement, je pense que ça n'en vaut pas la peine et qu'il vaut mieux supprimer les dépêches inactives avant que plein de gens aient commencé à passer des heures à se demander ce qu'on en fait et à essayer de compléter.

      Le travail de remise à jour + les efforts pour essayer d'avoir un truc structuré et cohérent sont trop élevés, si bien que c'est plus simple de repartir de 0.

      Je pense par exemple à "la voiture allergique à la glace à la vanille", créée par quelqu'un qui a juste mis un lien vers un site en anglais et demandé la permission à l'auteur de ce site de faire une traduction, et n'a pas donné suite. J'ai rédigé quelques paragraphes dedans, mais ça ne m'intéresse pas plus que ça (sous cette forme en tout cas… il y aurait des choses à dire sur comment les légendes urbaines se forment), j'aurais mieux fait de la laisser mourir.

      Maintenant j'éviterai de faire des modifs de ce genre sur les dépêches inactives pour ne pas les garder en vie plus longtemps que nécessaire.

    • [^] # Re: Six mois plus tard

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

      En supprimant une dépêche (manuellement donc, lors d'un nettoyage de printemps), est-ce qu'il y a quand même une sauvegarde derrière ? Un peu comme un git rm, il y aurait quand même moyen de récupérer le contenu en revenant en arrière dans l'historique ?

      Si jamais l'auteur original re-débarque 6 mois plus tard, et grogne "mais où est donc passée ma dépêche" ?

      Mais sinon, je pense qu'internet et le web sont déjà suffisamment chargés d'informations que pour vouloir à tout pris tout garder. Donc, autant supprimer, sans regrets. Quitte à faire un bête copier-coller en-dehors de LinuxFr, avant de supprimer du site.

      • [^] # Re: Six mois plus tard

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

        En supprimant une dépêche (manuellement donc, lors d'un nettoyage de printemps), est-ce qu'il y a quand même une sauvegarde derrière ?

        Cela dépend de comment est supprimé la dépêche.

        Il y a la méthode radicale - mais qui a priori est peu utilisée - qui ne laisse pas de trace.

        L'autre méthode envoie un mail à l'auteur de la dépêche avec une copie de celle-ci. C'est la méthode qui est normalement utilisée.

        Surtout, ne pas tout prendre au sérieux !

        • [^] # Re: Six mois plus tard

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

          L'autre méthode envoie un mail à l'auteur de la dépêche avec une copie de celle-ci. C'est la méthode qui est normalement utilisée.

          Et elle reste en DB.

          « 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: Six mois plus tard

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

      Par contre, je pense que c’est une règle quasi-générale, il faut supprimer les dépêches qui n’ont plus d’activité lors des derniers 12 mois.

      Entièrement d'accord. Ça pourrait même être divisé par 2 à mon avis.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

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.