URL: https://linuxfr.org/news/compte-rendu-de-la-tchache-linuxfrorg-du-28-novembre Title: Compte‐rendu de la tchache LinuxFr.org du 28 novembre Authors: Benoît Sibaud Bruno Michel, baud123, Davy Defaud, patrick_g et Lucas Bonnet Date: 2011年11月28日T23:10:20+01:00 License: CC By-SA Tags: linuxfr Score: 17 La première « tchache » avec l’équipe de _LinuxFr.org_ (par IRC et XMPP gentiment synchronisés par un _bot_) a eu lieu le 28 novembre entre 21 h et 22 h 20. Le sujet principal était l’espace de rédaction. Vous trouverez dans la seconde partie de la dépêche une version remise au propre des échanges. Merci à tous ceux qui ont posé des questions. ---- [Tchatche LinuxFr.org : l’espace de rédaction](http://linuxfr.org/news/tchatche-linuxfrorg%C2%A0-l%E2%80%99espace-de-r%C3%A9daction) ---- Bonsoir à toutes et à tous, nous avons le plaisir de vous accueillir ce soir pour cette première « tchache » _LinuxFr.org_, afin de répondre à toutes vos questions sur le thème de « l’espace de rédaction ». **Question : Qui s'est déjà connecté à l'espace de rédaction sur http://linuxfr.org/redaction ? (et a rédigé ou initié une dépêche pour toucher 50 points de karma ?)** **Oumph** : moi, j'ai dû rédiger mes 3 ou 4 dernières de cette façon (y compris lorsque j'étais le seul auteur). **NoNo** : pareil, je rédige toutes mes dépêches en passant par l'espace de rédaction. **claudex** : j'y ai rédigé toutes mes dépêches depuis que l'espace existe (c'est-à-dire depuis la migration) sauf une qui était initialement prévue comme journal. baud vient de temps en temps sur l'espace de rédaction pour corriger les dépêches ou faire des retours sur la tribune (il y a Nÿco qui fait office de flux rss). **Nils** : Je l'ai fait pour ma dernière dépêche, sans trop de succès cependant. **Nÿco** : toujours. **patrick_g** : je le fais aussi pour les dépêches noyau ce qui permet d'avoir des contributions sur la traduction des annonces de RC. Mais j'avoue que je préfère rédiger dans mon coin. C'est difficile d'intégrer les textes des autres je trouve. **Question : Serait-il possible de savoir le nombre de points de karma lorsque l'on rédige une dépêche et qu'elle est acceptée ?** **Oumph** : la réponse est 50. Cf https://linuxfr.org/aide#aide-karma **baud123** : + les points obtenus grâce au pertinentage ensuite (de la dépêche) **NoNo** : après, on gagne aussi des points de karma pour la note de la dépêche. Les dépêches ont une note moyenne de 30, je dirais donc on peut espérer gagner 80 points de karma par dépêche. **Question : Quelles sont les modifications récentes de l'espace de rédaction ? Et celles à venir ?** **Nÿco** : Celles que vous allez tous/toutes proposer... ;-). **NoNo** : pour les modifications récentes : avant toutes les modifications arrivaient dans la tribune de rédaction, ce qui la rendait très difficile à lire ; maintenant, il y a juste les discussions qui vont dans la tribune associée à la dépêche. Les modifications sont listées en dessous, sous la forme d'une liste de révisions. Chaque révision peut être affichée sous forme de diff. **patrick_g** : C'est très pratique d'avoir ces modifications sous forme de diff au lieu de n'avoir qu'une copie du paragraphe modifié. Grosse amélioration. **NoNo** : Autre modification, pour modifier un paragraphe ou un lien, il fallait cliquer dessus. Ce qui n'était pas pratique, on avait tendance à cliquer dessus sans le vouloir. Maintenant, il y a un bouton avec un crayon qui apparaît au survol du paragraphe/lien pour passer en mode édition. ça a un effet de bord intéressant : on peut compte le nombre de clics sur les liens et s'assurer que chaque lien a bien été visité par au moins une personne. **baud123** : et vous pouvez lister [celles à venir ou à compléter](http://linuxfr.org/suivi?utf8=%E2%9C%93&tracker%5Bstate%5D=opened&tracker%5Bcategory_id%5D=24&tracker%5Bassigned_to_user_id%5D=&order=created_at&commit=Filtrer) (celles effectuées sont aussi détaillées sur [la dépêche récente des évolution du site LinuxFr.org](http://linuxfr.org/news/%C3%A9volutions-du-site)). **NoNo** : la troisième modification importante est la gestion des verrous. Quand on édite un paragraphe, si par malheur, on ferme sa fenêtre, on peut quand même repasser en mode édition sur ce paragraphe. Ce n'était pas le cas avant. Et si on oublie de revenir, le verrou va être automatiquement libéré au bout de 20 minutes. Avant, il fallait obligatoirement être l'auteur de la dépêche ou un AMR (== admin/modérateur/relecteur), et libérer tous les verrous de la dépêche. **claudex** : la liste des participants a aussi été ajoutée. **baud123** : (mais pas mise en public pour l'instant, comme c'était le cas avant) **NoNo** : pour les modifications à venir : la principale, ça va être de pouvoir éditer une dépêche en entier, pas juste un paragraphe à la fois, c'est particulièrement important pour réorganiser une dépêche. Par exemple, déplacer du contenu de la première partie de dépêche en seconde partie. Ensuite, il y a beaucoup de demandes dans le suivi, l'endroit qui nous sert à gérer les remontées de bugs et les propositions d'améliorations mais je ne sais pas encore ce qui va être dans un futur proche, et ce qui attendra que j'ai plus de temps. **Question : Quel est l'intérêt de l'espace de rédaction au fait ? Qu'est-ce que ça apporte par rapport à soumettre directement sa dépêche soi-même ?** **Nÿco** : la collaboration, l'entraide, les contributions, le partage, le fun, le suivi, la couverture, la discussion, en bref... le libre quoi ! **claudex** : On peut avoir l'expertise d'autres personnes qui connaissent bien le sujet mais n'avaient pas forcément la motivation de tout rédiger **oumph** : L'espace de rédaction est collaboratif et contributif. On y écrit à plusieurs. Certains viennent relire, d'autres ajouter des liens, préciser tel ou tel point, ajouter des images (sous licences libres de préférence), etc. **Nÿco** : ah oui, et il y a aussi deux types de rédacteurs : les commenceurs et les finisseurs... ça permet de réunir les deux et de faire des article entiers ;-). **claudex** : Ça peut aussi servir d'espace de brouillon et les modérateurs et relecteurs peuvent déjà corriger ou conseiller des sujets à aborder. **oumph** : Par ailleurs cela permet aussi d'avoir un espace de discussion sur la dépêche en préparation. **NoNo** : il y a le côté collaboratif et contributif **NoNo** : c'est sympa de voir des gens proposer des améliorations à sa dépêche, la compléter, ajouter des liens mais ça a aussi des cotés pratiques, même quand on veut rédiger sa dépêche tout seul d'un coup. **Nils** : un avantage des côtés collaboratifs et contributifs est que certains pourront proposer des améliorations de tournures assez profondes, en particulier si la dépêche a un ton trop journal ou communiqué de presse, ce qui évite de passer par la case "refus de dépêche, merci de la réécrire" **NoNo** : ça évite d'avoir plusieurs dépêches sur le même sujet; notamment quand elles sont liées à l'actualité (une distrib qui sort) **baud123** : idéalement (pour des sorties de distro par exemple, cela devrait permettre de rédiger un contenu adapté pour une dépêche LinuxFr pour des gens qui n'auraient pas forcément participé au wiki des contributeurs de la distro). **NoNo** : ça peut faire office de brouillon. On peut s'arrêter au milieu de la dépêche et revenir le lendemain depuis un autre ordinateur pour finir sa dépêche. Et en plus, des fois, on découvre que quelqu'un a proposé d'autres liens intéressants sur le même sujet (c'est du vécu) **patrick_g** : Un des avantages c'est aussi de réduire les duplications de travail qui pouvaient exister auparavant quand deux contributeurs proposaient une news sur le même sujet. **Question : Où se trouve la charte de rédaction de linuxfr.org ?** **claudex** : http://linuxfr.org/regles_de_moderation **NoNo** : comme pour tout, faut chercher sur le plan : http://linuxfr.org/plan ;-) **oumph** : Disons que ce qui est rédigé passe en modération, donc les règles de modération correspondent pas mal aux règles de rédaction de fait. Il est toutefois possible d'envisager des conseils supplémentaires de forme, de fond, etc. Par ailleurs des conseils de collaboration pourraient être donnés pour aider les gens à travailler à plusieurs efficacement disons. **Nÿco** : la charte évolue pas mal au cours du temps et nos expériences. Globalement, elle reste la même, ce sont les détails qui changent **oumph** : Nous sommes preneurs de suggestions sur la charte de modération ou sur une charte de rédaction en général. **Nÿco** : genre, nous avons discuté de ceci : lorsque l'article est long, il devient nécessaire de réduire la première partie, et de sectionner la seconde par des titres (h2). On bataille pas mal sur les règles de typo du français, mais surtout on vérifie l'info, et son adéquation avec la ligne éditoriale du site. **NeoX** : clair que veiller aux espaces fines insécables pour décider ou non de publier, c'est quand même capilotracté. **Question : Existe-t-il une liste de diffusion des rédacteurs pour se coordonner, proposer des sujets, définir qui fait quoi, etc. ?** **Nils** : il y a la tribune de rédaction : http://linuxfr.org/redaction mais pas de liste de diffusion par mail. À noter que les dépêches dans l'espace de collaboration ont un espace de discussion. **baud123** : pas encore, mais [il y a une entrée dans le suivi pour cela](http://linuxfr.org/suivi/mailing-list-r%C3%A9dacteurs). **Nÿco** : ce serait bien, effectivement, comme c'est un outil traditionnel, et que chacun s'y retrouve avec son propre MUA (client mail), par rapport à l'interface web. **Question : Est-ce qu'il ne serait pas intéressant d'introduire la notion d’événement, auxquels les rédacteurs habitués pourraient s'abonner (signaler qu'ils sont généralement sur ce sujet) ? Cela pourrait introduire beaucoup de facilités pour la collaboration.** **Nÿco** : excellente idée !l y a déjà http://linuxfr.org/readings . À cette page, pourraient s'ajouter les articles de rédaction, etc. **claudex** : J'en avais déjà parlé il me semble mais ça demande du boulot et je ne suis pas sûr que beaucoup de monde suivrait mais je trouve aussi que c'est une bonne idée. **baud123** : ah un rss des rédactions à venir, comme suggéré sur [la page wiki thèmes récurrents](//linuxfr.org/wiki/themes-recurrents) oui, ça peut être proposé :-) vu que le process reste à créer **Nils** : ça peut être vraiment sympa :) **NoNo** : pourquoi pas **Question : Est-il envisageable d'étendre le système de rédaction collaborative aux journaux ?** **lukhas** : hmm. Si c'est pour en faire un super journal complet, autant proposer une dépêche, non ? Ou alors j'ai pas saisi le but :) **baud123** : o_O y a le wiki pour cela ou sinon, pourquoi ne pas faire une dépêche ? **Nÿco** : je ne vois pas très bien l'intérêt... d'autre part, sur le côté technique je laisse NoNo répondre... **NoNo** : techniquement, ça demanderait beaucoup de boulot et un journal a un côté très personnel. Donc, si c'est pour se donner autant de mal, autant faire une dépêche. Au pire, il y a moyen de faire ça dans l'espace de rédaction en marquant en haut de la dépêche qu'elle va être transformée en journal, puis, quelqu'un fait le copier-coller en journal. Ce n'est pas top, mais je ne vais pas me lancer dans les journaux en mode collaboratif avant un bout de temps. **Nils** : j'ai aussi du mal à voir l'intérêt, le journal peut perdre de son instantanéité, ce que je trouve dommage. **Question : Est-ce qu'il serait possible d'avoir des retours sur les corrections effectuées lors de la relecture ? Par exemple, si on écrit trop à la première personne... Cela peut permettre aux gens de ne pas refaire les mêmes erreurs et diminuer ainsi le travail de relecture.** **NoNo** : c'est déjà un peu le cas pour les dépêches refusées, mais on pourrait donner plus de détails. **Nÿco** : d'une manière générale, la première personne est utilisée dans les journaux. Pour les articles à la première personne, il y a une section pour cela (Humeur). mais oui, au moment de la validation, on doit pouvoir envoyer le diff ? NoNo ? **claudex** : C'est une bonne idée mais il faudrait réussir à avoir un diff correct entre la première et la dernière correction pour que ce soit exploitable **NoNo** : en l'état, non mais ça peut se coder, juste que je ne suis pas convaincu que le diff soit très intéressant sans explications. **baud123** : euh bin il y a [cette liste de suggestions pour les relecteurs](http://demoll.tuxfamily.org/linuxfr/SuggestionsRelecteurLinuxFr) qui donnait quelques conseils de relecture pouvant servir à la rédaction, reste à le reprendre sur le wiki :-) **Question : Est-il envisageable de pouvoir se passer un jour de l'interface web de linuxfr.org pour rédiger et de pouvoir faire ça par un système de versionnement ? (quitte à valider l'état définitif soit par un tag, soit par l'interface web)** **NoNo** : un jour, peut-être. Mais pour le moment, ça paraît très improbable. C'est très complexe à gérer. **Nÿco** : je ne vois pas très bien comment, car beaucoup de process sont spécifiques, il faudrait pas mal de hooks. **Nils** : peut-être en créant un web service, avec une API ? Mais j'imagine que cela reviendrait à refaire le site de A à Z... **NoNo** : par exemple, chaque dépêche est associée à une section, comment marquer cela dans un dépôt git ? **claudex** : ça me semble aussi fort compliqué pour un intérêt fort limité **Nÿco** : aaah, la mode de Git... ;-) **NoNo** : Nils : on pourrait faire une API, mais ça ne répond pas à la demande et ne présente pas forcément un très grand intérêt. **Question : Pourra-t-on un jour utiliser weboob pour rédiger collaborativement une dépêche ?** **Nÿco** : pourquoi pas... **NoNo** : je n'en sais rien, ça dépend surtout des développeurs de weboob **Nils** : faut demander aux développeurs de weboob, non ? **neox** : nils : +1 **NoNo** : pour le moment, je ne crois pas qu'ils aient fait la moindre demande sur le suivi dans ce sens **Nÿco** : c'est-à-dire que l'interface bouge pas mal surtout en ce moment... **Question : Pour rebondir sur le côté personnel des journaux, cela peut aussi concerner également les dépêches, et globalement si l'on est peu adepte de la collaboration pour la rédaction de contenu. Peut-être que la possibilité de soumettre une dépêche sans collaboration possible pourrait être envisagée ?** **Nÿco** : c'est là : http://linuxfr.org/news/nouveau **oumph** : sans les avantages du mode brouillon, donc il faut la rédiger en une fois, au lieu de pouvoir la créer et la compléter ensuite, avant l'envoi en modération. **Nÿco** : de toute façon, la dépêche est vérifiée, revue et corrigée par l'équipe d'édition **baud** : euh ouais, mais bon quand il reste tout à rédiger, faut soit connaître le sujet, soit être motivé donc préférer l'espace de rédaction initialement **NoNo** : je pense que l'on peut utiliser l'espace de rédaction, avec une petite note en haut disant que l'on veut travailler tout seul dessus **Question : y a-t-il des règles pour coder (coding styles) pour développer sur le site ?** **NoNo** : c'est du ruby on rails, donc ça se résume principalement à suivre les bonnes pratiques en ruby et en rails, rien de bien méchant. **Nÿco** : http://linuxfr.org/code_source_du_site **baud123** : j'ai tenté [un documentation de l'organisation du code de LinuxFr.org](//linuxfr.org/wiki/organisation-code-linuxfr) mais cela reste améliorable :-) et visiblement un contributeur s'en est passé d'après [ce retour et une proposition de patch](http://linuxfr.org/suivi/patch-possibilit%C3%A9-d%C3%A9diter-les-commentaires) (j'aimerais bien un retour comment il s'est débrouillé, il a peut-être demandé à NoNo de lui installer son instance ?). Il prétend que ça lui a pris 4 à 8h, ce n'est pas tant que cela. **NoNo** : non, il ne m'a rien demandé **baud123** : eh beh **NoNo** : j'ai découvert le patch sur le suivi **baud123** : on aurait une liste de discussion, il aurait pu être plus prolixe (ah, mon oreillette m'indique qu'on a une liste) **Question : Manifestement une base de test bien garnie faciliterait bien la tâche (genre un extrait de la base de production). Possibilité d'avoir un micro-export de la BDD pour faire tourner en local plus facilement ?** **Oumph** : il n'y en a pas besoin pour commencer. Ça se remplit quand même facilement la base (j'ai aussi une instance). **baud123** : sur les dév' il reste à créer une communauté : sur les CSS (le concours a apporté du contenu, pas forcément des contributeurs dans la durée :/ et il nous manque des graphistes ainsi que des testeurs et un process pour essayer sur l'alpha) **NoNo** : moi, je me suis créé des contenus au fur et à mesure **Oumph** : voilà, pareil, pour coder les stats notamment **NoNo** : le problème d'un micro-export, c'est que c'est très facile de leaker des informations personnelles **baud123** : si tu complètes http://linuxfr.org/wiki/organisation-code-linuxfr visiblement oumph et NoNo t'indiqueront comment te passer d'une base complète :-) **claudex** : je l'avais aussi lancé il y a quelques temps sans problème (mais sans base) **baud123** : bin en fait le suivi est ponctuel (une fois que c'est corrigé c'est oublié), le wiki est plus inscrit dans le présent : cela précise comment participer à un instant t

AltStyle によって変換されたページ (->オリジナル) /