Je rejoins antistress sur le manque d'utilité, anéfé ton éditeur fait l'affaire.
Encore une fois, pour contrer le risque d'oubli de telles dépêches, on va encore devoir coder des système de bascule auto en rédaction ouverte. De plus, les flux se retrouvent pour le coup un tantinet compliqués.
Le ratio apports contre emmerdements (et leurs garde-fous) me semble réellement en défaveur notable d'un tel statut et chemin.
Il y a le chemin journal -> dépêche aussi : tu le rajoutes ?
Et anéfé, les redacteurs devraient pouvoir pousser des journaux en rédaction.
Remarque : dépêches en finalisation/modération vote pour la publication : rédacteur + au moins X modérateurs => les rédacteurs et modérateurs ont donc un rôle très très proche…
Continuons à creuser, j'essaie de comprendre et paraphraser, je tente de structurer mon discours.
TL;DR : ce n'est pas tout à fait en phase avec les objectifs, mais on peut converger et trouver de bonnes idées.
Brouillon
Je ne vois que très peu l'intérêt d'ouvrir d'un côté et fermer de l'autre, je parle des brouillons fermés d'un côté et de l'autre de la modération ouverte. Rappel, on a https://linuxfr.org/news/nouveau qu'on peut - certes - peut-être améliorer en ce sens. Je lis que tu proposes en sus de la route « ouverte » Rédaction > Modération > Publication, la nouvelle route « privée » Brouillon > Modération > Publication, qui existe déjà en passant par https://linuxfr.org/news/nouveau mais à la différence que les rédacteurs peuvent relire et corriger. Cela équivaut à avoir une modération ouverte.
Note bien, qu'il existe différents « types » de rédacteurs : les « commenceurs » qui démarrent mais ne sont pas contents de leur travail, disent que ce n'est pas fini, et ne considèrent jamais que c'est switchable à un autre état ; les « retoucheurs » qui révisent, corrigent, structurent, suggèrent de manière pertinente et contribuent de manière tout autant significative que les autres ; et enfin il y a les « finisseurs » qui font les retouches finales de type last mile que les autres n'ont pas su/pu faire. Avec les commenceurs, une partie de la population que l'on vise avec les brouillons privés, leurs brouillons ne basculeront jamais ou peu en rédaction ou modération, et on va se retrouver avec des contenus bloqués en sommeil qu'on ne verra jamais… et qui auraient gagné à être revus par les retoucheurs et finisseurs. Note : cette modélisation est intrinsèquement limitée, on est bien tous d'accord.
Avec un existant, des risques de blocages, et un workflow à implémenter, je ne vois toujours pas l'intérêt d'un statut brouillon, qui je le rappelle restera à coder.
C'est un besoin personnel fort, je le comprends, mais qui ne va pas vraiment dans le sens d'une rédaction ouverte et collaborative. C'est comme un patch qui dort dans un git perso, et une contribution Wikipédia forcément visible de tous.
Fusion
On est donc d'accord que tu proposes la fusion des espaces de rédaction et de modération.
Tu déplaces donc ici le rôle modérateur un peu plus vers la rédaction, mais toujours pas vers la modération des commentaires, ce qui est une priorité du site. Certes les modérateurs ne sont pas assez impliqués en rédaction, ce serait donc un bien.
Avec la rédaction d'aujourd'hui, les dépêches qui tombent en modération sont de bien meilleure qualité que par le passé sans rédaction, et donc le travail à faire des modérateurs sur les dépêches s'en trouve amoindri. Donc les modérateurs ont gagné en temps, qu'ils devraient à mon sens consacrer à la modération de commentaires.
Finalisation
Je ne vois toujours pas, ni ne comprends, l'intérêt et les contours d'un état « Finalisation ». Pour moi, ça représente l'espace de modération actuel. Dans le cadre de la fusion de la rédaction et modération, tout le monde aura eu le loisir de retoucher, donc l'auteur place un flag « À voter », ce que les modérateurs feront, et publieront.
En lieu de ce statut, on peut ouvrir en lecture/écriture l'espace de modération actuel aux rédacteurs, ce qui serait sans doute un élément motivateur, une preuve de transparence, et un désenclavement des deux équipes de modération et rédaction. Note que cela ressemble au statut de relecteur, récemment supprimé. Rappel, les modérateurs sont encouragés à aller rédiger, les rédacteurs respectivement seront donc les bienvenus en modération.
Objectifs
Là, ça n'adresse qu'assez peu les problèmes actuels de la rédaction et de la modération, à savoir qu'on manque d'abord de contributeurs à la rédaction et d'activité en modération de dépêches et de commentaires, le sommeil des dépêches pose problème, comme le déclenchement du passage en modération, les infos du monde du LL et sujets afférents non-couvertes par LinuxFr.org, et surtout surtout je répète la modération des commentaires. Le problème « pâté » que tu as soulevé n'est pas couvert non plus.
Avec ces idées et réflexions collaboratives, on n'adresse que des process qui ne posent pas, ou pas encore, de problèmes.
Priorités
Je réaffirme donc les priorités :
modération de dépêches active et réactive
modération de commentaires réactive
avec des modifications de commentaires abusifs
et des interventions dans les fils de discussion à problème
rédaction de plus de dépêche, meilleure couverture de l'info
deux développeurs pour aider NoNo
Ensuite, on pourra rajouter nos petits problèmes :
modifier le bouton « Soumettre cette dépêche » en « Soumettre en modération » ou « Proposer à la publication »
Rajouter un bouton « Soumettre en rédaction »
Tu proposes aussi peut-être de sauver ses propres brouillons ? Dans ce cas, il est nécessaire que tes brouillons perso soient visibles et déblocables.
Ce qu'il manque peut-être c'est un moyen de partager les idées et propositions de dépêches et les intentions d'en écrire. On a la tribune, mais ce n'est clairement pas suffisant.
Donc le workflow serait : Idée/proposition ► brouillon perso visible ► édition active avec ou sans participants ► finalisation/relecture ► (modération) ► publication (tout le process et tous les états étant visibles, ouverts, transarents)
Un brouillon peut être collaboratif, d'expérience, on l'a fait plein de fois. Et puis celui qui crée la dépêche n'est pas forcément celui qui fait le remplissage initial. Cette étape n'est à mon sens pas nécessaire, et complique plutôt le flux.
Les dépêches en modération qui sont passées par la rédaction n'ont souvent plus de finalisation à faire, cad corrections, clics des liens, et ligne éditoriale, mais juste une publication bête et méchante, le travail étant fait plus en amont, en rédaction.
Je tente la paraphrase, pour bien suivre et tenter d'enrichir.
Si je comprends bien, tu veux casser le passage de rédaction en modération, en virant l'espace de modération actuel, pour ne faire qu'un espace de rédaction, sur lesquels collaborent différents profils, cad rédacteurs et modérateurs, ces derniers pouvant publier à partir de là.
C'est pas mal, j'aime bien l'idée, mais… Il y a un « mais ». Cela est équivalent à une modération avec relecteurs, à l'ancienne, la différence se situant dans l'ouverture de la modération.
Donc le statut rédacteur deviendrait relecteur (renommé « rédacteur »), que l'on vient juste de supprimer… ;-)
On voit le soucis arriver : la modération actuelle (vérification des liens, corrections, alignement ligne éditoriale, etc.) se fait aujourd'hui de manière fermée. Ce serait un énorme changement. Cela signifierait qu'on supprime l'espace de modération actuelle pour n'avoir que la rédaction à partir de laquelle les modérateurs pourraient publier, et que quiconque pourrait lire et écrire sur les articles en modération.
Cela implique, je suppose, que les news en état de modération dans l'espace de rédaction seraient bloquées en édition (voire en lecture) pour les non-rédacteurs par exemple.
D'autre part, on a des dépêches qui dorment alors qu'elles sont prêtes, ou pas. Le passage en modération pose problèmes, tous les contributeurs n'étant pas forcément d'accord quant à son passage en modération. Parfois l'auteur initial ne voit pas le bouton « Soumettre la dépêche », ou bien il ne connait pas le processus, ou bien on n'est pas clairs, etc. Parfois, c'est les contributeurs qui veulent rajouter un truc ou deux. Parfois c'est la date qui presse le passage en modération. Parfois c'est l'inverse, la dépêche étant prête bien en avance, on passe le bébé aux modérateurs, qui publieront en temps voulu, mais qui râlent car ils ont un dépêche endormie à laquelle ils doivent penser à la date idoine.
D'autre part, tu le critiquais dans la ML modérateurs@, et je te rejoins sur ce sujet, la liste des dépêches en rédaction est un gros « pâté ». Anéfé, il serait judicieux de faire des petits tas, au lieu de gros pâtés. Comment sectionner ? Par statut de dépêche, moins de 1000 caractères, plus de deux liens, une image d'illustration, présence d'une seconde partie, plus de deux contributeurs… Je ne sais pas trop.
Synthèse. Donc on a aujourd'hui deux espaces dans lesquels on travaille sur les dépêches. Ta proposition : on fusionne les deux, et on fonctionne par état des dépêches et rôles des humains. Je te comprends bien ?
Vue en bullet-points :
fusion de l'espace de modération et de l'espace de rédaction
Je vous propose d'expérimenter les notes/commentaires, de façon manuelle pour l'instant, en insérant ce genre de note, sous le paragraphe auquel il est rattaché :
Note de Pseudo (à retirer avant soumission à la modération) : Texte suggérant des trucs ou posant des questions.
Syntaxe :
citations avec un > en première colonne
gras avec ** au début et à la fin du texte
Le texte « Note de Pseudo (à retirer avant soumission à la modération) : » (en remplaçant pas votre pseudo, bien évidemment
Votre texte libre suggérant des trucs ou posant des questions.
Pour les channels/MUC rédacteurs, ce sera ouvert à mon sens, au contraire de modérateurs et admins. Que risque-t-on sans TLS ?
Y a deux choses distinctes :
protéger le compte du bot et son authentification
Sur XMPP, c'est built-in.
protéger les discussions
ça veut aussi dire qu'il faudrait que la connexion IRC soit faite en SSL/TLS (mais ça n'empêche pas de voir quelqu'un débarquer sur le canal ou dans le salon, et de regarder ce qui ce dit, surtout s'il y a un backlog).
Donc au pire, le mec a un chatlog, au pire du pire, avec des infos sensibles dedans ? Mais pas les droits d'accès aux serveurs…
Je n'ai pas compris les usurpations de pseudos… C'est côté IRC seulement ?
C'est en tout cas vrai côté IRC apparemment. Je ne sais pas pour le côté XMPP.
Sur un service de MUC, on peut réserver des pseudos. Le nom du compte, lui, reste identifié et authentifié.
À cette heure, seuls les modérateurs ont commenté ce ticket. Mais cela concerne l'équipe de rédacteurs, dont le formalisme avance petit à petit au cours du temps, mais qui suite à l'arrivée réelle de ce statut permettra beaucoup de nouvelles choses.
Braindump brouillonesque :
Un statut ?
Mais qu'est-ce qu'on entend par « statut » ? En fait, c'est un ensemble de droits qu'on a en plus des utilisateurs normaux. Un peu comme l'ensemble des droits spécifiques aux modérateurs. Ces deux ensembles ayant (en l'état de réflexion actuelle) une intersection non-nulle.
Pour quoi faire ?
Pour renforcer l'idée qu'un rédacteur est engagé et régulier, c'est une forme de reconnaissance et de confiance. Àmha ce statut rédacteur sera donné à un utilisateur - avec son accord - après délibération des rédacteurs actuels. C'est une cooptation également, comme cela se fait chez les modérateurs.
Engagements
Je pense que cela motivera pas mal de monde, car vous serez intégrés dans les réunions et discussions liées à LinuxFr.org, pas seulement la rédaction, mais élargies à la modération, l'admin, le dev, et toutes les évolutions du site.
Salons
Faisant partie intégrante des équipes du site, en tant que rédacteurs, vous serez amenés à représenter LinuxFr.org lors des salons, réunions, événements en tout genre.
Bref
On va mettre l'accent sur la rédaction, car c'est la raison d'être du site.
Si on met en place des notifs, autant utiliser ce qui est déjà existant, comme par exemple les notifs de dépêches publiées sur la ML modéros ;-) La symétrique n'est pas en place
Ensuite, si ce n'est que la mise à jour de la page, soit tu mets un refresh côté client (extension), soit on en fout un côté serveur, mais ce n'est qu'une demie solution et plutôt chiante. L'idéal serait effectivement la notif a minima dans l'onglet, via qqch comme SSE ou websockets ? Sinon on peut mettre un client XMPP BOSH dans la page, qui ne servirait qu'à la notif ?
Euh, sinon, tu as fait deux journaux, tu veux peut-être écrire une news maintenant ? On t'aide à la rédaction, si besoin : http://linuxfr.org/redaction
Ce sont plutôt des informations méta que des données de chat : nature différente, à ne pas mélanger à mon sens. Mais la chronologie a son importance… Je plussoie néanmoins ce besoin d'informations.
relancer des contributeurs de dépêches qui semblent orphelines
mail sur la ML rédacteurs ? Dans ce cas, contributeurs en copie caché s'ils ne sont pas inscrits à la ML rédacteurs et incitation à venir discuter sur la tribune de l'article concerné.
C'est ce que je fais déjà manuellement, c'est très consommateur.
un ajout à discuter :
possibilité d'éditer des journaux 1 h après leur publication (pour de l'orthographe, prise en compte des commentaires genre correction d'url…) => à discuter (notamment le 1 h…)
Pour quoi faire ? La capacité d'édition des journaux est plutôt à la charge des modéros, en cas d'abus.
permettrait de voir les posts des rédacteurs mis en valeur sur la tribune générale de rédaction (via une petite étoile ou autre)
sérieux ? des gommettes, comme en primaire ?
Et pourquoi pas ?
On (modors, rédacos) pourrait avoir un highlight dans n'importe quelle partie du site, quand on écrit en tant que {modo|admin|rédac}.
Amhà, dans un premier temps, identifier une liste des rédacteurs sur http://linuxfr.org/team serait dans la continuité ;-)
De toute évidence, on ne coupe pas à un boulot d'inventaire de tous les endroits où apparaissent les autres équipes et y rajouter les rédacos, dans un soucis d'homogénité, bien entendu. Il s'agit dans ce ticket de dégrossir.
L'intérêt d'une dépêche, c'est de l'avoir en dépêche ?
Sur le site, les dépêches sont bien plus lues que les journaux et plus commentées
En externe, les flux RSS/Atom montrent déjà des différences significatives
Côté réseaux sociaux, les dépêches sont diffusées, les journaux ne le sont pas
Et puis écrire une dépêche permet de passer par la rédaction collaborative, qui va te permettre d'enrichir l'article…
…et de passer ensuite par la modération, qui va appliquer la ligne éditoriale du site, et va passer les dernières corrections et ajouts nécessaires.
Pour ceux que ça intéresse, quelque soit le type de contenu, tu peux gagner des bouquins et abonnements… mais bien évidemment aec des articles étoffés.
[^] # Re: En place
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi relance pour dépêches collaboratives. Évalué à 3 (+0/-0).
Oh yeah, trop bon ! ;-) merci…
[^] # Re: un mode brouillon pourrait correspondre à un mode privé
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 3 (+0/-0).
Je rejoins antistress sur le manque d'utilité, anéfé ton éditeur fait l'affaire.
Encore une fois, pour contrer le risque d'oubli de telles dépêches, on va encore devoir coder des système de bascule auto en rédaction ouverte. De plus, les flux se retrouvent pour le coup un tantinet compliqués.
Le ratio apports contre emmerdements (et leurs garde-fous) me semble réellement en défaveur notable d'un tel statut et chemin.
[^] # Re: Pas de vote avant la modération
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 3 (+0/-0).
Ah bien joué comme ça, on voit bien la synthèse.
Il y a le chemin journal -> dépêche aussi : tu le rajoutes ?
Et anéfé, les redacteurs devraient pouvoir pousser des journaux en rédaction.
Remarque : dépêches en finalisation/modération vote pour la publication : rédacteur + au moins X modérateurs => les rédacteurs et modérateurs ont donc un rôle très très proche…
[^] # Re: Mes notes
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 3 (+0/-0).
Sommaire
Continuons à creuser, j'essaie de comprendre et paraphraser, je tente de structurer mon discours.
TL;DR : ce n'est pas tout à fait en phase avec les objectifs, mais on peut converger et trouver de bonnes idées.
Brouillon
Je ne vois que très peu l'intérêt d'ouvrir d'un côté et fermer de l'autre, je parle des brouillons fermés d'un côté et de l'autre de la modération ouverte. Rappel, on a https://linuxfr.org/news/nouveau qu'on peut - certes - peut-être améliorer en ce sens. Je lis que tu proposes en sus de la route « ouverte » Rédaction > Modération > Publication, la nouvelle route « privée » Brouillon > Modération > Publication, qui existe déjà en passant par https://linuxfr.org/news/nouveau mais à la différence que les rédacteurs peuvent relire et corriger. Cela équivaut à avoir une modération ouverte.
Note bien, qu'il existe différents « types » de rédacteurs : les « commenceurs » qui démarrent mais ne sont pas contents de leur travail, disent que ce n'est pas fini, et ne considèrent jamais que c'est switchable à un autre état ; les « retoucheurs » qui révisent, corrigent, structurent, suggèrent de manière pertinente et contribuent de manière tout autant significative que les autres ; et enfin il y a les « finisseurs » qui font les retouches finales de type last mile que les autres n'ont pas su/pu faire. Avec les commenceurs, une partie de la population que l'on vise avec les brouillons privés, leurs brouillons ne basculeront jamais ou peu en rédaction ou modération, et on va se retrouver avec des contenus bloqués en sommeil qu'on ne verra jamais… et qui auraient gagné à être revus par les retoucheurs et finisseurs. Note : cette modélisation est intrinsèquement limitée, on est bien tous d'accord.
Avec un existant, des risques de blocages, et un workflow à implémenter, je ne vois toujours pas l'intérêt d'un statut brouillon, qui je le rappelle restera à coder.
C'est un besoin personnel fort, je le comprends, mais qui ne va pas vraiment dans le sens d'une rédaction ouverte et collaborative. C'est comme un patch qui dort dans un git perso, et une contribution Wikipédia forcément visible de tous.
Fusion
On est donc d'accord que tu proposes la fusion des espaces de rédaction et de modération.
Tu déplaces donc ici le rôle modérateur un peu plus vers la rédaction, mais toujours pas vers la modération des commentaires, ce qui est une priorité du site. Certes les modérateurs ne sont pas assez impliqués en rédaction, ce serait donc un bien.
Avec la rédaction d'aujourd'hui, les dépêches qui tombent en modération sont de bien meilleure qualité que par le passé sans rédaction, et donc le travail à faire des modérateurs sur les dépêches s'en trouve amoindri. Donc les modérateurs ont gagné en temps, qu'ils devraient à mon sens consacrer à la modération de commentaires.
Finalisation
Je ne vois toujours pas, ni ne comprends, l'intérêt et les contours d'un état « Finalisation ». Pour moi, ça représente l'espace de modération actuel. Dans le cadre de la fusion de la rédaction et modération, tout le monde aura eu le loisir de retoucher, donc l'auteur place un flag « À voter », ce que les modérateurs feront, et publieront.
En lieu de ce statut, on peut ouvrir en lecture/écriture l'espace de modération actuel aux rédacteurs, ce qui serait sans doute un élément motivateur, une preuve de transparence, et un désenclavement des deux équipes de modération et rédaction. Note que cela ressemble au statut de relecteur, récemment supprimé. Rappel, les modérateurs sont encouragés à aller rédiger, les rédacteurs respectivement seront donc les bienvenus en modération.
Objectifs
Là, ça n'adresse qu'assez peu les problèmes actuels de la rédaction et de la modération, à savoir qu'on manque d'abord de contributeurs à la rédaction et d'activité en modération de dépêches et de commentaires, le sommeil des dépêches pose problème, comme le déclenchement du passage en modération, les infos du monde du LL et sujets afférents non-couvertes par LinuxFr.org, et surtout surtout je répète la modération des commentaires. Le problème « pâté » que tu as soulevé n'est pas couvert non plus.
Avec ces idées et réflexions collaboratives, on n'adresse que des process qui ne posent pas, ou pas encore, de problèmes.
Priorités
Je réaffirme donc les priorités :
Ensuite, on pourra rajouter nos petits problèmes :
[^] # Re: Mes notes
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 3 (+0/-0). Dernière modification le 30 avril 2013 à 14:08.
Tu l'as déjà ça : https://linuxfr.org/news/nouveau
Àmha, il ne reste qu'à :
Tu proposes aussi peut-être de sauver ses propres brouillons ? Dans ce cas, il est nécessaire que tes brouillons perso soient visibles et déblocables.
Ce qu'il manque peut-être c'est un moyen de partager les idées et propositions de dépêches et les intentions d'en écrire. On a la tribune, mais ce n'est clairement pas suffisant.
Donc le workflow serait : Idée/proposition ► brouillon perso visible ► édition active avec ou sans participants ► finalisation/relecture ► (modération) ► publication (tout le process et tous les états étant visibles, ouverts, transarents)
# Mes notes
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 4 (+0/-0). Dernière modification le 30 avril 2013 à 12:17.
Un brouillon peut être collaboratif, d'expérience, on l'a fait plein de fois. Et puis celui qui crée la dépêche n'est pas forcément celui qui fait le remplissage initial. Cette étape n'est à mon sens pas nécessaire, et complique plutôt le flux.
Les dépêches en modération qui sont passées par la rédaction n'ont souvent plus de finalisation à faire, cad corrections, clics des liens, et ligne éditoriale, mais juste une publication bête et méchante, le travail étant fait plus en amont, en rédaction.
Je tente la paraphrase, pour bien suivre et tenter d'enrichir.
Si je comprends bien, tu veux casser le passage de rédaction en modération, en virant l'espace de modération actuel, pour ne faire qu'un espace de rédaction, sur lesquels collaborent différents profils, cad rédacteurs et modérateurs, ces derniers pouvant publier à partir de là.
C'est pas mal, j'aime bien l'idée, mais… Il y a un « mais ». Cela est équivalent à une modération avec relecteurs, à l'ancienne, la différence se situant dans l'ouverture de la modération.
Donc le statut rédacteur deviendrait relecteur (renommé « rédacteur »), que l'on vient juste de supprimer… ;-)
On voit le soucis arriver : la modération actuelle (vérification des liens, corrections, alignement ligne éditoriale, etc.) se fait aujourd'hui de manière fermée. Ce serait un énorme changement. Cela signifierait qu'on supprime l'espace de modération actuelle pour n'avoir que la rédaction à partir de laquelle les modérateurs pourraient publier, et que quiconque pourrait lire et écrire sur les articles en modération.
Cela implique, je suppose, que les news en état de modération dans l'espace de rédaction seraient bloquées en édition (voire en lecture) pour les non-rédacteurs par exemple.
D'autre part, on a des dépêches qui dorment alors qu'elles sont prêtes, ou pas. Le passage en modération pose problèmes, tous les contributeurs n'étant pas forcément d'accord quant à son passage en modération. Parfois l'auteur initial ne voit pas le bouton « Soumettre la dépêche », ou bien il ne connait pas le processus, ou bien on n'est pas clairs, etc. Parfois, c'est les contributeurs qui veulent rajouter un truc ou deux. Parfois c'est la date qui presse le passage en modération. Parfois c'est l'inverse, la dépêche étant prête bien en avance, on passe le bébé aux modérateurs, qui publieront en temps voulu, mais qui râlent car ils ont un dépêche endormie à laquelle ils doivent penser à la date idoine.
D'autre part, tu le critiquais dans la ML modérateurs@, et je te rejoins sur ce sujet, la liste des dépêches en rédaction est un gros « pâté ». Anéfé, il serait judicieux de faire des petits tas, au lieu de gros pâtés. Comment sectionner ? Par statut de dépêche, moins de 1000 caractères, plus de deux liens, une image d'illustration, présence d'une seconde partie, plus de deux contributeurs… Je ne sais pas trop.
Synthèse. Donc on a aujourd'hui deux espaces dans lesquels on travaille sur les dépêches. Ta proposition : on fusionne les deux, et on fonctionne par état des dépêches et rôles des humains. Je te comprends bien ?
Vue en bullet-points :
[^] # Re: Fait
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Flux des dépêches publiées : ajouter les contributeurs. Évalué à 3 (+0/-0).
Wow, merci ! ;-)
# Expérimentation
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Annotation dans l'éditeur collaboratif. Évalué à 3 (+0/-0).
Je vous propose d'expérimenter les notes/commentaires, de façon manuelle pour l'instant, en insérant ce genre de note, sous le paragraphe auquel il est rattaché :
Syntaxe :
[^] # Re: Résumé des essais en cours
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Passerelle IRC/XMPP. Évalué à 3 (+0/-0).
Sur XMPP, c'est built-in.
Donc au pire, le mec a un chatlog, au pire du pire, avec des infos sensibles dedans ? Mais pas les droits d'accès aux serveurs…
Sur un service de MUC, on peut réserver des pseudos. Le nom du compte, lui, reste identifié et authentifié.
[^] # Re: Résumé des essais en cours
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Passerelle IRC/XMPP. Évalué à 3 (+0/-0).
Merci pour ces essais et ce rapport ! On y voit plus clair.
Pour les channels/MUC rédacteurs, ce sera ouvert à mon sens, au contraire de modérateurs et admins. Que risque-t-on sans TLS ?
Je n'ai pas compris les usurpations de pseudos… C'est côté IRC seulement ?
Quel était le bot que tu as utilisé lors des causeries ?
[^] # Re: Précisions importantes
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Création d'un statut « Rédacteur ». Évalué à 3 (+0/-0).
Vu le milieu geek, plutôt bière…
# Précisions importantes
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Création d'un statut « Rédacteur ». Évalué à 4 (+0/-0).
À cette heure, seuls les modérateurs ont commenté ce ticket. Mais cela concerne l'équipe de rédacteurs, dont le formalisme avance petit à petit au cours du temps, mais qui suite à l'arrivée réelle de ce statut permettra beaucoup de nouvelles choses.
Braindump brouillonesque :
Un statut ?
Mais qu'est-ce qu'on entend par « statut » ? En fait, c'est un ensemble de droits qu'on a en plus des utilisateurs normaux. Un peu comme l'ensemble des droits spécifiques aux modérateurs. Ces deux ensembles ayant (en l'état de réflexion actuelle) une intersection non-nulle.
Pour quoi faire ?
Pour renforcer l'idée qu'un rédacteur est engagé et régulier, c'est une forme de reconnaissance et de confiance. Àmha ce statut rédacteur sera donné à un utilisateur - avec son accord - après délibération des rédacteurs actuels. C'est une cooptation également, comme cela se fait chez les modérateurs.
Engagements
Je pense que cela motivera pas mal de monde, car vous serez intégrés dans les réunions et discussions liées à LinuxFr.org, pas seulement la rédaction, mais élargies à la modération, l'admin, le dev, et toutes les évolutions du site.
Salons
Faisant partie intégrante des équipes du site, en tant que rédacteurs, vous serez amenés à représenter LinuxFr.org lors des salons, réunions, événements en tout genre.
Bref
On va mettre l'accent sur la rédaction, car c'est la raison d'être du site.
Donc exprimez-vous svp !
[^] # Re: Pas pour
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Notifications xmpp. Évalué à 3 (+0/-0).
Si on met en place des notifs, autant utiliser ce qui est déjà existant, comme par exemple les notifs de dépêches publiées sur la ML modéros ;-) La symétrique n'est pas en place
Ensuite, si ce n'est que la mise à jour de la page, soit tu mets un refresh côté client (extension), soit on en fout un côté serveur, mais ce n'est qu'une demie solution et plutôt chiante. L'idéal serait effectivement la notif a minima dans l'onglet, via qqch comme SSE ou websockets ? Sinon on peut mettre un client XMPP BOSH dans la page, qui ne servirait qu'à la notif ?
# Pas pour
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Notifications xmpp. Évalué à 3 (+0/-0).
Tous les modos sont sur la ML, mais pas tous sur XMPP/IRC du fait de proies/firewalls de m*rde.
Pour moi, la notif XMPP/IRC est un petit plus, une option.
Pour les notifs ML, voir :
https://linuxfr.org/suivi/notifications-sur-listes-de-diffusion
Note, on a déjà les flux ATOM :
https://linuxfr.org/redaction/news.atom
https://linuxfr.org/redaction/news/moderation.atom
[^] # Re: bonnes idées
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Création d'un statut « Rédacteur ». Évalué à 4 (+0/-0).
http://openbadges.org/ ?
[^] # Re: Publicité éhontée
Posté par Nÿco (site web personnel) . En réponse au journal TowTruck. Évalué à 2.
Je l'ai mentionné dans la news à paraître.
Euh, sinon, tu as fait deux journaux, tu veux peut-être écrire une news maintenant ? On t'aide à la rédaction, si besoin : http://linuxfr.org/redaction
[^] # Re: Publicité éhontée
Posté par Nÿco (site web personnel) . En réponse au journal TowTruck. Évalué à 5.
Avoue qu'au niveau marketing, « dépanneuse » c'est mieux que « mangez des poneys »… ;-)
[^] # Re: Fait
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Flux RSS/Atom pour les dépêche en rédaction et modération. Évalué à 3 (+0/-0).
Merci ! ;-)
[^] # Re: Réattribution de paternité
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Création d'un statut « Rédacteur ». Évalué à 3 (+0/-0). Dernière modification le 21 avril 2013 à 18:11.
http://linuxfr.org/suivi/ajout-d-informations-complementaires-dans-la-tribune-d-une-depeche-en-redaction-moderation
# s/tribune/meta/ ?
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Ajout d'informations complémentaires dans la tribune d'une dépêche en rédaction/modération. Évalué à 4 (+0/-0).
Ce sont plutôt des informations méta que des données de chat : nature différente, à ne pas mélanger à mon sens. Mais la chronologie a son importance… Je plussoie néanmoins ce besoin d'informations.
[^] # Re: Fait
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Flux RSS/Atom pour les dépêche en rédaction et modération. Évalué à 3 (+0/-0). Dernière modification le 21 avril 2013 à 17:56.
Dans https://linuxfr.org/plan il y a :
Les dépêches
Il faut maintenant rajouter cela ?
Les dépêches
[^] # Re: bonnes idées
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Création d'un statut « Rédacteur ». Évalué à 3 (+0/-0).
C'est ce que je fais déjà manuellement, c'est très consommateur.
Pour quoi faire ? La capacité d'édition des journaux est plutôt à la charge des modéros, en cas d'abus.
Et pourquoi pas ?
On (modors, rédacos) pourrait avoir un highlight dans n'importe quelle partie du site, quand on écrit en tant que {modo|admin|rédac}.
De toute évidence, on ne coupe pas à un boulot d'inventaire de tous les endroits où apparaissent les autres équipes et y rajouter les rédacos, dans un soucis d'homogénité, bien entendu. Il s'agit dans ce ticket de dégrossir.
[^] # Re: Proposé en dépêche
Posté par Nÿco (site web personnel) . En réponse au journal TowTruck. Évalué à 4.
L'intérêt d'une dépêche, c'est de l'avoir en dépêche ?
# Proposé en dépêche
Posté par Nÿco (site web personnel) . En réponse au journal TowTruck. Évalué à 4.
Voici la news en rédaction : http://linuxfr.org/redaction/news/towtruck
# Mouais
Posté par Nÿco (site web personnel) . En réponse à l’entrée du suivi Ajouter un bouton preview pour l'édition de paragraphe. Évalué à 3 (+0/-0).
Finalement, en repassant dessus, on peut peut-être virer cette entrée…