Journal De l’espace de rédaction Linuxfr

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
42
9
fév.
2024

Salut vieux Nal,

Ça fait un bail qu’on se connait, toi et moi. Un récent sondage me semble même confirmer que l’on est une majorité de vieilles moules à trainer par ici.

Ce dont je voulais te parler, c’est de la rédaction des dépêches.

Je ne sais pas si tu sais, mais sur Linuxfr, il y a un espace collaboratif de rédaction de dépêches. Je ne pense pas que tout le monde y aie accès. C’est peut-être réservé. Ou peut-être pas.

Cet espace part d’une excellente intention: permettre de rédiger une dépêche collaborativement. De la relire, la corriger. Etc.

Sauf que, en pratique, cet espace fait à mon sens pire que mieux.

Aujourd’hui, il contient 28 dépêches en instance de rédaction. La plus ancienne date de mai 2022. Certaines de ces dépêches ont une temporalité importante : décès d’une personnalité, traduction d’une newsletter datée. Et pourtant, elles sont toujours en suspens car pas terminée.

Le pas terminé va de "quelqu’un a balancé le sujet avec trois liens en espérant que la dépêche s’écrive toute seule" à "la dépêche est en train de devenir un long dossier qui s’étoffe, se dilue, perd son focus avec des dizaines de commentaires sur la direction à prendre".

C’est particulièrement dommageable car la plupart de ces dépêches auraient gagnées à être publiées, même imparfaites. Certaines peuvent être supprimées, malgré l’effort mis dedans : cela n’a plus de sens de les publier aujourd’hui. D’autres sont de tels chantiers qu’elles demandent un gros effort. Et c’est dommage parce que, je peux vous le dire, il y a des contenus vraiment très intéressant. Qui méritent mieux que d’être corrigés/effacés par 10 modérateurs sans que personne ne puisse lire le contenu.

Cela fait 25 ans que j’écris sur le Web et, de mon expérience, ce n’est pas propre à Linuxfr. L’écriture collaborative n’est générablement pas compatible avec le concept de publication. Chaque ouvrage écrit nécessite un maître d’œuvre clair qui fait l’essentiel du boulot et qui décide, à un moment donné, d’arrêter les frais et de publier. Les dépêches publiées sur Linuxfr sont de ce ressort : un auteur clairement identifié n’utilise l’espace de rédaction que pour faire son travail en prenant d’éventuels retours mais en rédigeant essentiellement seul et en lobbyant parfois intensément pour la publication rapide.

À l’opposé, on a le modèle Wikipédia mais où, justement, il n’y a pas de publication. Tout changement est directement visible et où, par essence, un article n’est jamais terminé.

Lorsqu’une personne bien intentionnée lance un sujet de dépêche sur Linuxfr mais ne le porte pas jusqu’au bout, quelle qu’en soit la raison, l’ébauche devient un sujet de discussion, de contributions, d’efforts. Essentiellement gâché.

Sortir de ce marasme rédactionnel n’est pas évident.

Une idée de solution qui me vient à l’esprit:

  • Une dépêche doit sortir de l’espace de rédaction après une semaine. Après une semaine, la dépêche est automatiquement proposée à la modération et est soit refusée, soit publiée.

Cette règle aurait pour effet d’éviter le pourissement des dépêches. Les modérateurs pourraient encore faire des corrections si nécessaire mais on ne serait plus dans la longue discussion. Si une dépêche doit mettre plus d’une semaine à s’écrire collaborativement, cela signifie qu’elle doit être travaillée en dehors de l’espace de rédaction. L’espace de rédaction n’est pas là pour commencer à un brouillon à partir de rien ou pour lancer un débat sur comment parler d’un sujet. L’auteur doit prendre la responsabilité de produire une dépêche ou une structure de dépêche plus ou moins claire et presque publiable dès le début.

Je pense que Linuxfr aurait tout a gagné à revenir à plus de dépèches, plus courtes, plus dynamiques, plus réactives avec l’actualité.

Mes 2 centimes…

  • # Plus flexible

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

    Idée intéressante.
    Que penses tu si on laissait le choix de cette «dead line» au rédacteur originel lui même ?

    Comme tu le dit, certaines dépêche n’ont pas la même temporalité que d’autre (actu VS dossier), du coup leur imposer un même délai ne me semble pas adapté.

    Mais je suis d’accord qu’il faut «motiver» les gens en leur posant des limites (Loi_de_Parkinson), quitte a les repousser (Loi_de_Hofstadter).

    • [^] # Re: Plus flexible

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

      Je vois deux alternatives :

      1. soit on considère que l’espace de rédaction n’est pas adapté à la création de longs et complexes dossiers.

      2. Soit on différencie clairement les dépêches des dossiers (le nom "dépêche" est assez parlant). On ne choisit pas une deadline, on dit si on poste une dépêche ou un dossier. Mais cela revient à peu près à la situation actuelle pour une grande partie des propositions.

      La solution 2 introduit une nouvelle complexité et je me pose la question de savoir pourquoi un groupe arbitraire d’utilisateurs de Linuxfr seraient subitement des contributeurs appropriés pour n’importe quel dossier.

      Pour moi, soit un dossier doit se faire avec une équipe donnée en fonction du sujet et donc sur une plateforme faite pour (un framapad par exemple), soit le dossier est ouvert à tout le monde et on parle d’un wiki.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Plus flexible

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

        Pour moi, soit un dossier doit se faire avec une équipe donnée en fonction du sujet et donc sur une plateforme faite pour (un framapad par exemple),

        bin l'avantage de la rédaction c'est sa tribune sur le côté permettant de discuter des sujets en cours d'édition (tu retrouves la même notion sur un pad)

        soit le dossier est ouvert à tout le monde et on parle d’un wiki

        moui, les dossiers pourraient aller dans le wiki ou en dépêche tagguée dossier ou un tag plus représentatif ;-) un peu comme cela est fait pour les journaux_du_mois

        l'inconvénient du wiki c'est que l'édition se fait sur la page entière et que les commentaires deviennent souvent obsolètes (un peu comme sur une mailing-list) et qu'il n'y a pas de tribune :/

  • # Bon sujet de discussion

    Posté par  . Évalué à 10 (+16/-1).

    Tu devrais initier une dépêche pour en parler.

    • [^] # Re: Bon sujet de discussion

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

      ouais, je crois que c'est intéressant

      • TODO : ajouter un lien sur la rédaction
      • et un autre qu'il faut que je retrouve, qu'étais bien, il est dans un de mes signets, je met là

      y'a pas jean-roger qu'avait fait un truc similaire?

      Sinon, il faut pas oublier que l'écriture d'une dépêche revêt une importance capitale dans notre société moderne, où les opinions et les journaux guident souvent nos choix. Exprimer ses impressions sur un logiciel, un service ou une expérience permet non seulement d'aider les autres informaticiens, mais aussi d'influencer les décisions des entreprises. C'est un acte de responsabilité sociale et de contribution à l'amélioration constante de la qualité. Chaque mot choisi reflète une expérience personnelle et peut avoir un impact significatif sur le destinataire. Les avis éclairés favorisent une meilleure transparence et une confiance accrue entre les consommateurs et les fournisseurs. Leur rédaction nécessite donc une réflexion approfondie et une expression claire des sentiments ressentis. Par conséquent, prendre le temps d'écrire un (<- penser à sinthétiser, et après on peut poster)

      • [^] # Re: Bon sujet de discussion

        Posté par  (site web personnel, Mastodon) . Évalué à 10 (+9/-0). Dernière modification le 09 février 2024 à 15:56.

        C'est pas toi qui a écrit ça ! (ou alors pas tout seul, et si c'est toi, tu devrais avoir honte de voler le boulot de ChatGPT).

        « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # l'âge d'une dépêche est corrélé à l'âge des auteurs zé autrices

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

    il ne faudrait pas oublier que l'âge aidant, des contraintes (familiales ?) surgissent inopinément pour ralentir brusquement notre écriture.

  • # Mais oui !

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

    Je suis bien d'accord avec ce que tu décris, l'écriture collaborative ne fonctionne pas si personne ne prend les rênes. À mon humble avis celui qui commence une rédaction devrait être prêt à tout faire tout seul si nécessaire, quitte à en supprimer des bouts pour que ça se termine. C'est comme pour les logiciels, il vaut mieux que ça sorte même si ça pourrait être mieux plutôt que de chercher la perfection.

    Après il manque un truc à LinuxFr.org c'est de pouvoir envoyer des messages directement aux utilisateurs. Pouvoir pinguer quelqu'un pour lui demander de contribuer sur un point précis, ou lui rappeler qu'on l'attend, ça aiderait pas mal.

    • [^] # Re: Mais oui !

      Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 09 février 2024 à 16:19.

      Après il manque un truc à LinuxFr.org c'est de pouvoir envoyer des messages directement aux utilisateurs. Pouvoir pinguer quelqu'un pour lui demander de contribuer sur un point précis, ou lui rappeler qu'on l'attend, ça aiderait pas mal.

      c'est fait régulièrement par les modérateurs, tu peux t'abonner à la mailing-list rédaction pour t'en assurer :-)

  • # passage en journal

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

    au lieu de > /dev/null une depeche vieille, je propose le passage en journal en l’état, ni vu ni connu.
    Même si c'est sur la mort de francois mitterand, ca relance le debat

    une petite mention au debut : ancienne depéche publié en l’état, pour faire valoir ce que quoi de droit (toujours rêver de le placer !)

    • [^] # Re: passage en journal

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

      Très bonne idée
      Les commentaires du journal pourraient servir à repasser le journal en dépêche… :-)

  • # précisions rédaction

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

    ploum< tu m'étonnes de ne pas connaître certains des fonctionnement de LinuxFr.org o_O

    Le fonctionnement de l'espace de rédaction est pourtant documenté sur la page éponyme du wiki.

    il y a un espace collaboratif de rédaction de dépêches. Je ne pense pas que tout le monde y aie accès. C’est peut-être réservé. Ou peut-être pas.

    il suffit d'être identifié en tant que contributeur (donc, simple utilisateur du site) pour y avoir accès : en lecture, en édition, et même en réorganisation (édition de la globalité de la dépêche).

    Un rôle d'animateur de l'espace de rédaction permet d'aller plus loin comme indiqué dans l'aide à l'animation

    Cela a permis de réduire la durée de modération comme visible sur https://linuxfr.org/statistiques/moderation#temps_depeches

    Un récent sondage me semble même confirmer que l’on est une majorité de vieilles moules à trainer par ici.

    tu as des stats d'ancienneté des comptes actifs sur les 3 derniers mois :

    plus de 20 ans : 26%

    1999 36 2%
    2000 50 2%
    2001 157 7%
    2002 166 7%
    2003 179 8%

    moins de 20 ans : 74% d'après https://linuxfr.org/statistiques/users#stats_anciennete

    pour le sondage, tu faisais allusion à Cher lectorat, chèr(e) contributeurice, quel âge avez-vous ? ou à Depuis quand suivez vous LinuxFr.org ? ? — Sachant que 100% des sondages sont orientés ou non représentatifs et que 74,76% des statistiques sont fausses :D

    Qui méritent mieux que d’être corrigés/effacés par 10 modérateurs sans que personne ne puisse lire le contenu.

    il y a 12 modérateurs + 4 admins soit plutôt 16 personnes pouvant modérer les dépêches après soumission et 7 personnes en rédacteurs pouvant proposer à la modération les dépêches commencées en rédactions + les plus de 2000 personnes s'étant identifiées sur les 3 derniers mois pouvant éditer les dépêches en rédaction.

    cf. https://linuxfr.org/equipe et https://linuxfr.org/aide#aide-authentification pour les différents droits octroyés dès lors qu'on s'identifie sur LinuxFr.org (ce qui permet de participer un peu plus, notamment en nourjal mais aussi en rédaction :p).

    vala vala, il y a de quoi faire :-) Merci ploum pour ta relance de la dynamique de l'espace de rédaction _o/

  • # Proposition alternative

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

    1: Une dépêche devrait avoir un et un seul gestionnaire. Un projet à 4 têtes, on sait que ça ne fonctionne jamais. Le créateur de la dépêche devrait en être le chef de projet. Les autres sont des contributeurs, ils peuvent contribuer, mais pas changer de direction, discuter pendant des semaines sur ce qu'il faut y mettre ou pas sans atteindre de consensus.
    Bon, en pratique, ça veut dire que l'auteur devrait prendre les contributions comme des "pull-request", et ça demande de coder des trucs, et non, je ne sais pas coder, encore moins en RoR.

    2: Un temps limite devrait être fixé à l'avance. Ça peut être une semaine, à condition que toute intervention de l'auteur initial repousse la date d'une semaine. Comme ça si l'auteur veut poursuivre mais que c'est pas le moment, il/elle peut juste aller cliquer "repousser la date d'expiration" une fois par semaine.

    3: Si rien n'y est apporté après expiration, les modos décident s'ils la publient en l'état, comme un journal, ou s'ils l'archivent.

    4: Une dépêche archivée disparaît de l'espace de rédaction mais tombe dans un espace d'archives et le gestionnaire en perd la gestion. Le prochain volontaire qui va la reprendre devient automatiquement son nouveau gestionnaire.
    L'archive est conservée 1an avant d'être définitivement effacée si plus personne ne reprend.

  • # Entrée de suivi pour "Réduire la liste des dépêches en cours de rédaction"

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

    Il y a quelques années (déjà !), j'avais ouvert une entrée de suivi pour essayer d'être plus conviviale aux contributeurs en réduisant la liste des dépêches en cours de rédaction: https://linuxfr.org/suivi/reduire-la-liste-de-depeche-en-cours-de-redactions

    Au début, l'idée était de cacher la liste trop longue, mais après j'ai vu que Ruby on Rails pouvait tout à fait faire une gestion automatisée des brouillons: https://linuxfr.org/suivi/reduire-la-liste-de-depeche-en-cours-de-redactions#comment-1833799

    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

    3 ans après, rien ne s'est passé, je ne sais plus si c'est intéressant comme idée.

    • [^] # Re: Entrée de suivi pour "Réduire la liste des dépêches en cours de rédaction"

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

      3 ans après, rien ne s'est passé, je ne sais plus si c'est intéressant comme idée.

      euh bin, perso je ne l'ai pas vu :D

      j'imagine que peu des rédacteurs non plus ? (réponse souhaitée)
      autant le garder sous le coude comme une évolution (qui a des impacts collatéraux)

      mais oui, bienvenue au cercueil^Wcercle des bonnes idées tombées en désuétude :/

    • [^] # Re: Entrée de suivi pour "Réduire la liste des dépêches en cours de rédaction"

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

      Il y a deux ans et demi, j'écrivais :

      Suite à mon premier journal sur le sujet, Adrien Dorsaz a introduit une entré de suivi. N’hésitez pas à contribuer au débat si cela vous intéresse.

      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 rares, 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

      Aujourd'hui, j'aurais tendance à penser que si ce n'est pas trop compliqué comme fonction à mettre en place, on pourrait faire 3 tâches cron :

      1. Une première tâche qui repère quand un brouillon de dépêche n'a pas été mise à jour depuis 6 mois. Cette tâche envoie un email de relance comme les animateurs peuvent le faire. Ce même message est publié sur la tribune de la dépêche
      2. Une deuxième tâche qui repère quand un brouillon de dépêche n'a pas été mise à jour depuis 11 mois 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 4 semaines si aucune modification n'y est apportée. Ce même message est publié sur la tribune de la dépêche
      3. Une dernière tâche qui prend tous les brouillons de dépêche dont la dernière modification remonte à plus de 12 mois Elle passe la dépêche de l'état "brouillon" à "supprimer" 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 les tâches cron ne coûtent pas chers, on pourrait mettre une phase 0 identique au point 1 après 3 mois.

      Sinon, encore mille merci pour ton travail sur le message de relance. Chaque fois que je dois écrire un message de relance, je te remercie silencieusement de l'évolution.

      Surtout, ne pas tout prendre au sérieux !

  • # Parlons des dépêches qui fonctionnent

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

    Globalement, le système fonctionne bien, la plupart des dépèches finissent quand même par être publiées, même si certaines prennent pas mal de temps.

    Certaines sont menées par une seule personne ou un petit groupe. Mais même dans ce cas là, les "petites" contributions et relectures sont bonnes à prendre pour améliorer le contenu avant qu'il arrive entre les mains de la modération (j'espère que vous ne m'en voulez pas trop pour mes textes de 10 kilomètres sur Haiku ou les évolutions du langage C).

    Il y a quand même des choses qui ont pas trop mal fonctionné. Récemment j'ai en tête les bonnes résolutions de début d'année, et avant ça, une lecture collective d'un livre sur C++ qui je pense a été enrichissante pour les participants à la rédaction, peut-être plus que pour les lecteurs? Effectivement dans ces cas là, il y a une personne qui a pris les choses en main.

    D'autres cas où ça se passe moins bien: les dépêches entamées suite au décès d'une personalité de l'informatique: la meilleure solution serait de préparer ce genre de dépêche à propos de personne encore vivantes. Mais je trouve ça intéressant d'avoir des portraits un peu élaborés et un retour en détail sur l'oeuvre accomplie. C'est incompatible avec la publication dans l'actualitédes évènements.

    Enfin je pense à une autre dépêche qui a eu une gestaion difficile, celle sur la voiture qui n'aimait pas la glace à la vanille. Elle a empilé deux problèmes: un abandon par l'initiateur de la dépêche, et l'objectif initial était de faire une traduction d'un texte existant, mais le texte initial s'est avéré mal sourcé et peu fiable. Malgré tout, je crois que le résultat était intéressant.

    Il reste le problème des textes abandonnés en cours de route, et de ceux où quelqu'un (je crois que c'st souvent la même personne) dépose trois liens en vrac puis disparaît sans laisser de traces. OsDans ces cas là, je pense effectivement qu'il vaut mieux, soit publier en l'état, soit supprimer le truc si personne ne s'empare du sujet. La prochaine fois, postez un lien ou un journal pour lancer les débats, ce sera plus intéressant.

    Voilà, c'était mun retour personnel pour les dépêches auxquelles j'ai plus ou moins participé.

  • # Mes 22 centimes...

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

    Je ne sais pas si vous avez remarqué mais Ploum, souvent, sur les réseaux sociaux, il ressort ses posts de blog au gré de l'actualité et des discussions. Comme Ploum est un exemple pour moi :

    Quelques commentaires-réflexions complémentaires

    Les dépêches publiées sur Linuxfr sont de ce ressort : un auteur clairement identifié n’utilise l’espace de rédaction que pour faire son travail en prenant d’éventuels retours mais en rédigeant essentiellement seul et en lobbyant parfois intensément pour la publication rapide.

    Excellente idée. Il y aurait un auteur ou une autrice pour chaque dépêche. Elle-lui aurait à tout moment le droit de soumettre la dépêche pour publication. Et l'équipe de modération validerait la publication en moins d'une semaine après soumission (sauf si vraiment la qualité est insuffisante).
    Tellement une excellente idée que c'est comme cela que fonctionne l'espace de rédaction ;-)

    Une idée de solution qui me vient à l’esprit:

    • Une dépêche doit sortir de l’espace de rédaction après une semaine. Après une semaine, la dépêche est automatiquement proposée à la modération et est soit refusée, soit publiée.

    Alors, tu es plus radical que moi sur les délais mais, en tant qu'animateur de l'espace de rédaction, je propose régulièrement la suppression de dépêches.

    Je pense que Linuxfr aurait tout a gagné à revenir à plus de dépèches, plus courtes, plus dynamiques, plus réactives avec l’actualité.

    Je pense que personne ne sera en désaccord avec cela. Je pense néanmoins que l'espace de rédaction n'est en aucune façon responsable de l'évolution. Le problème se situe plutôt au trop peu de rédacteurices. Et de manière pas tout à fait négligeable, il y a une série de journaux qui auraient toute leur place comme dépêche mais certaines personnes idéalisent à mon sens un peu trop ce que doit être une dépêche.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Mes 22 centimes...

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

      Et de manière pas tout à fait négligeable, il y a une série de journaux qui auraient toute leur place comme dépêche mais certaines personnes idéalisent à mon sens un peu trop ce que doit être une dépêche.

      Les dépêches mettent beaucoup moins en avant l'auteurice (son avatar n'est pas affiché par exemple), et le passage en modération (ou les interventions d'autres contributeurs dans l'espace de rédaction) aboutissent parfois à des modifications relativement importantes.

      Le résultat est que les dépêches doivent d'une certaine façon, mieux suivre la ligne éditoriale du site et s'en tenir aux standards existants.

      De plus, l'existence d'un espace de rédaction qui permet de stocker un travail en cours, encourage à utiliser cette fonctionnalité, et donc à travailler sur des contenus longs, en y passant plus de temps. Pour les journaux il n'y a rien de tel, ça doit donc être rédigé en cuelques minutes et en une seule fois.

      Les journaux permettent un style et des sujets plus personnels. Rien qu'en voyant l'avatar en haut, on sait un peu à quoi s'attendre.

      En résumé (le "c'est trop long j'ai pas lu" comme on dit): l'interface utilisateur influe sur l'usage qui est fait du site, et inversement.

    • [^] # Re: Mes 22 centimes...

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

      Ha ben voilà, je m'étonnais que ton œuvre de fourmi ne soit pas cité dans le journal. L'occasion de te remercier pour ton travail épisodique régulier de tri de l'espace de rédaction et de tout ce qui va avec ;)

  • # Staging

    Posté par  (site web personnel) . Évalué à 10 (+10/-0). Dernière modification le 10 février 2024 à 10:41.

    Ma technique pour ne pas polluer : je commence mes dépêches dans mon dépôt git et je ne les mets dans l'espace de rédaction que quand elles sont assez abouties.

    En bonus, ça me permets de travailler un vrai éditeur de texte et gestionnaire de version :-)

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Staging

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

      Je pense que c’est la meilleure stratégie. Linuxfr est un site d’actualité, pas un site de rédaction communautaire. Ce sont deux choses différentes. Le focus sur la rédaction communautaire favorise, je pense, l’entre-soi et est plus difficile d’accès pour un nouvel arrivant.

      Le processus rend également la proposition de dépêche psychologiquement impressionnante et pourrait décourager les « petites contributions ».

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Staging

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

        En fait, tu dois être nouveau.

        Tu sais que passer par l'espace de rédaction collaboratif pour publier une dépêche est parfaitement optionnel ?

        Sinon, bon sujet de débat, LinuxFR est-il en partie, principalement ou uniquement un site d'actualité ?

        Il me semble que les sagas d'Oliver (sur Python et sur la téléphonie mobile) ont eu leur succès sans être des dépêches d'actualité.

        Amha, il y a aussi de la place dans les dépêches pour des trucs qui ne sont pas de l'actualité chaude.

        Surtout, ne pas tout prendre au sérieux !

      • [^] # Re: Staging

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

        Linuxfr est un site d’actualité

        {{référence nécessaire}}

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Staging

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

          Exactement !
          Je ne vois pas pourquoi il devrait être l'un ou l'autre.

        • [^] # Re: Staging

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

          L’utilisation du terme "dépêche" est quand même un indice assez flagrant.

          On pourrait arguer qu’il s’agit d’un artefact historique mais le fait que Linuxfr ne soit plus un site d’actualités n’a jamais été officiellement débattu ni acté, à ma connaissance.

          J’argue justement qu’on est actuellement dans une sorte d’entre-deux brouillon un rien dommage. (mais j’admets qu’il ne s’agit que d’une vision personnelle, partielle et partiale)

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: Staging

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

            Linuxfr est un site d'actualités qui publie aussi des articles de fond, comme la plupart des bons sites d'actualité (Nextinpact)

          • [^] # Terminologie

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

            L’utilisation du terme "dépêche" est quand même un indice assez flagrant.

            Il y a déjà plusieurs années, j’avais proposé un changement de terminologie (entre autres), mais ça n’a pas été couronné de succès.

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Mon expérience

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

    Salut,

    Personnellement, je suis vraiment très content du fonctionnement actuel.

    J'ai fait plusieurs très grosses dépêches et cela prend du temps, beaucoup de temps …

    Notre vie de moule, bien que parfois liée à nos actions professionnelles, n'est pas notre métier, de ce fait il n'est pas toujours possible d'avoir la ressource pour finir un travail. Ainsi poster un ébauche de dépêche permet de laisser la main si d'autres ont plus de temps.

    Je peux prendre l'exemple de la dépêche sur la RPi4 que j'avais lancée, j'ai vraiment été très content qu'il y ait d'autres rédacteurs pour revoir le style, et compléter les sujets que je maîtrise moins. Cela a été très agréable même si ça a duré un peu de temps.

    J'ai récemment lancé une dépêche sur la RPi5, on a clairement du temps avant qu'elle soit obsolète, et j'ai un peu moins le temps/motivation pour avancer dessus, la base est là et si quelqu'un veut avancer tant mieux, sinon cela attendra que je retrouve du temps/motivation, et cela m'agacerait prodigieusement que cela soit posté en l'état ou éffacé, je pense donc que cela n'est pas un vrai problème.

    Si de temps en temps un modo demande au rédacteur si il veut que l'on retire le sujet, et que la personne exprime le fait qu'elle ne veut plus toucher à ce brouillon, et que personne n'est motivé pour le reprendre, alors pas de pb pour l'effacer, dans les autres cas, je suis trouve que cela serait une source supplémentaire de démotivation, et les sources de démotivation, ce n'est pas ce qui manque dans notre monde …

    Voilà my 2 cents

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.