j'ai pas bien saisi ce qui portait vraiment à préjudice
Ce qui lui porte préjudice (et c'est vrai), c'est le fait que les remarques (avec critiques argumentées) portent directement sur son cœur de métier. Donc un client potentiel qui verrait ces remarques pourraient douter des compétences de l'entreprise pour faire faire un site web par exemple. Cette entreprise ne savait pas que les lecteurs réguliers de linuxfr sont souvent à la pointe de la technologie (entre autre, grâce aux nombreuses news qui passent ici) et très compétents dans pleins de domaines. C'est effectivement un bon endroit pour recruter. Maintenant, j'imagine que c'est un peu embêtant pour avoir envie de postuler pour cette entreprise (et également pour être client). Après, la solution peut être un changement de nom pour la boîte ou une solution de dernière minute pour éviter l'effet Streisand. C'est en effet très difficile de réagir correctement en lisant des critiques très fortes et justifiées et je veux bien croire que la réaction émotive prend le dessus.
J'ai (en tant que modérateur) repensé à votre dépêche. Le problème, c'est qu'elle n'est pas assez vendeuse par rapport à l'attente que vous avez et pas assez "honnête" par rapport au fait que c'est une première pour vous. Le bon niveau technique "exigé" est difficile à demander car ça vous coupe d'une partie des plus compétents, je parle des perfectionnistes très bons mais qui ne se jugent pas assez "bons". C'est votre rôle de déterminer si le niveau est bon ou pas.
Les explications données dans les commentaires auraient dû être dans la dépêche dès le départ pour cette première fois. Je vous suggère de refaire une dépêche pour remplacer celle-ci en expliquant tout. On enlèvera celle-ci le moment venu.
J'avais vu l'erreur avant la modération et je savais que les 'www' ne marchaient pas. Mais quand j'ai vu l'exigence d'un bon niveau technique pour le concours, je me suis dit que laisser cette erreur, ça laisserait les lecteurs de linuxfr mesurer la hauteur de cette exigence.
Bon, je vais corriger. Je n'avais jamais vu une news notée à -2 ceci-dit.
Il faudrait dans un premier temps que tu participes régulièrement à la correction ou relecture des dépêches dans l'espace de rédaction collaborative. D'ici quelques semaines, tu pourrais poser éventuellement ta candidature ?
au rédacteur d'utiliser son vote comme droit de véto (vote contre) qui peut aboutir au blocage de la publication. Il peut aussi voter "pour" à condition qu'il n'est pas trop impliqué. (Renfort de modération)
au (1/2) vote(s) modérateur(s) de donner quitus aux rédacteurs : vote par avance sans publication dans la foulée. Dans les autres cas, le modérateur publiera dès que le seuil de vote est atteint et donc ce sera le cas standard
Le conflit d'intérêt, on l'a actuellement en ce qui concerne les modérateurs qui rédigent beaucoup en partie rédaction et qui votent ensuite. Par principe, on pourrait bloquer le vote si le modérateur ou le rédacteur est l'auteur principal. Si on cherche à déterminer automatiquement si une édition est trop significative pour qu'un rédacteur ou modérateur ne puisse pas voter, on n'y arrive pas parce que c'est trop difficile à calculer.
Plutôt que de le coder, je propose que comme c'est le cas actuellement, un rédacteur ou un modérateur qui est soit l'auteur, soit a participé au delà de corrections mineures, ne vote pas ensuite.
On peut pousser le nombre minimal de vote modérateur à 2.
Si un modérateur participe souvent à la rédaction, c'est qu'il n'a pas le bon statut, du coup il passerait rédacteur.
C'est pour avoir un système souple et non rigide qui tienne compte de nos temps libres.
Afin d'avancer, je propose de créer un fil sur le mode de rédaction privé dans un autre ticket plus tard. L'objectif est de concentrer l'effort général sur la qualité de la rédaction et la vitesse de publication tout en ayant au moins 1 modération avant la publication.
Proposition n°3 :
[Rédaction]
Un seul espace de Rédaction (qui aurait une signification générale) visible de tous les utilisateurs sauf le contenu qui est fonction du rôle de l'utilisateur.
passage en modération : auteur + rédacteurs + modérateurs
remarque : le modérateur aurait un rôle de rédacteur volontaire et peut concentrer ses efforts sur la modération du site au sens général (commentaires/journaux/forums)
dépêches en modération :
visibilité dépêche :
auteur et participants en lecture seule
rédacteurs + modérateurs
visibilité tribune de la dépêche :
auteur + participants + rédacteurs + modérateurs
vote pour la publication : rédacteurs + modérateurs
publication (immédiate ou programmée) :
possible si seuil de vote (nombre pour - nombre contre) > au moins 3 modérateurs/rédacteurs "pour" dont 1 modérateur
possible par rédacteurs + modérateurs
retour en rédaction : possible par rédacteurs + modérateurs
Un seul espace de Rédaction (qui aurait une signification générale) visible de tous les utilisateurs sauf le contenu qui est fonction du rôle de l'utilisateur.
dépêches privées :
visibilité : auteur + utilisateurs invités
flux possible (par auteur) :
collaboratif
modération
date d'expiration du mode privé avant passage automatique en modération, repoussable en 1 clic si le/les auteurs ont besoin de plus de temps
flux possible (par auteur, rédacteurs, modérateurs) :
modération
remarque : le modérateur aurait un rôle de rédacteur volontaire et peut concentrer ses efforts sur la modération du site au sens général (commentaires/journaux/forums)
dépêches en modération :
visibilité dépêche :
auteur et participants en lecture seule
rédacteurs + modérateurs
visibilité tribune de la dépêche :
auteur + participants + rédacteurs + modérateurs
vote pour la publication : rédacteurs + au moins X modérateurs
flux possible :
publication (programmée ou immédiate) : possible par rédacteurs + modérateurs
retour en rédaction (privée ou collaborative) : possible par rédacteurs + modérateurs
le rédacteur a le droit de publier si au moins X modérateurs ont déjà voté pour
Je suggère de renommer le mode brouillon en mode privé :
J'ai proposé à Nyco de mettre un temps d'expiration (X jours) sur ce mode privé avant passage automatique en modération.
Peu avant la fin de l'expiration, un rappel est envoyé à l'auteur pour lui signaler que la dépêche va passer en modération. L'auteur peut éventuellement repousser la date en un clic s'il veut un peu plus de temps.
D'ailleurs, je pense qu'il pourrait vouloir inviter d'autres auteurs dans ce mode privé, ce qui apporterait l'avantage par rapport à un traitement de texte : mode de rédaction mais en privé avec des auteurs choisis, pour une préparation confidentielle.
Les Rédacteurs/Modérateurs sont complémentaires, l'un en priorité sur la Rédaction avec un pouvoir de vote et l'autre sur la Modération avec la possibilité de rédiger comme n'importe quel Rédacteur.
Il manque effectivement des détails dans mon schéma (je m'en rends compte après coup) mais si c'est sur la bonne piste, c'est pas mal.
Une fois que tout le monde s'accordera, on pourra demander le développement, qui va prendre peut-être du temps, et il faudra peut-être du renfort.
Je vais le corriger dans une autre réponse (je vais mettre un numéro au dessus pour pouvoir référencer la version).
remarque : le modérateur aurait un rôle de rédacteur volontaire et peut concentrer ses efforts sur la modération du site au sens général (commentaires/journaux/forums)
dépêches en finalisation/modération :
visibilité dépêche :
auteur et participant en lecture seule
rédacteur + modérateur
visibilité tribune de la dépêche :
auteur + participant + rédacteur + modérateur
vote pour la publication : rédacteur + au moins X modérateurs
flux possible :
publication (à date ou immédiate) : possible par rédacteur + modérateur
retour en rédaction
le rédacteur a le droit de publier si au moins X modérateurs ont déjà voté pour
dépêches avec publication programmée à une date :
"Titre 1" sera publié le XX/XX/2013 à XX/hXX
visibilité : auteur + participant + modérateur
Autre chose :
Donner le droit aux rédacteurs de proposer un journal en dépêche
Je soutiens le besoin du mode brouillon parce que tout le monde ne fonctionne pas de la même façon. L'auteur doit avoir le temps de travailler son texte comme il l'entend. Je suis sûr que ça pourrait motiver des personnes à au moins commencer quelque chose.
Je vois que tu as devancé l'élaboration de l'idée en améliorant la réflexion :
Il n'existerait qu'un espace "Rédaction" avec un grand "R".
Le modérateur est modérateur général : il veille sur le site, la charte, il relit mais sous un angle de modération de confirmation par un vote que c'est OK pour autorisation de publication
Le Rédacteur avec un grand "R" anime le nouvel espace de Rédaction soit en aidant les auteurs, soit en rédigeant lui-même une dépêche. Ce Rédacteur peut être choisi en fonction de ses critères de rédactions et aussi de son expertise sur certains sujets (dépêche noyau, embarqué,…).
Le Participant (n'importe quel utilisateur avec un compte) peut aider soit en devenant auteur ou en aidant à rédiger les dépêches en court de rédaction.
Au besoin de l'auteur, il pourrait demander à garder sa dépêche privée (case à cocher) pour que seuls les Rédacteurs (et modérateurs, admin) puissent la voir. Utile pour une information à ne pas diffuser tout de suite.
Donc c'est une ouverture générale à la Rédaction (et non plus nommée modération) sauf pour les dépêches "confidentielles".
Workflow :
la dépêche peut avoir un mode brouillon ou non
l'auteur propose la dépêche à la Rédaction (et non à la Modération)
l'auteur ET les Rédacteurs travaillent sur la dépêche
les Rédacteurs passent au moment où ils le souhaitent la dépêche dans un état "finalisation" ce qui peut se faire avant la fin de la rédaction
la dépêche passe en finalisation :
tout le monde peut encore éditer la dépêche, on va supposer qu'il faut faire confiance à ce que personne n'édite n'importe quoi entre deux clics de modération/rédaction/publication
le système de vote s'active pour les Participants, les Rédacteurs et les Modérateurs sauf pour l'auteur qui ne peut pas voter pour sa dépêche
les Modérateurs peuvent par avance rendre la dépêche publiable (peut-être avec un second système de vote)
la dépêche est publiable, les Rédacteurs et les Modérateurs peuvent publier si le système de vote de Rédaction ET de Modération sont OK
En ce qui concerne l'affichage sur le site, il faudrait que chacun voit bien les tâches qui le concernent.
Au passage une fonctionnalité utile : publication à une date donnée
Je verrais bien 3 systèmes de notification réglables par option pour chaque modérateur/relecteur (et utilisateurs pour d'autres choses) :
- la couleur de fond de l'onglet qui change de couleur (comme sur un webmail) et un site qui rafraîchit correctement les choses en les rendant rapidement identifiables sans devoir dérouler la page
- une notification personnelle (sur option) sur le compte xmpp
- une notification personnelle (sur option) sur le compte mail
- cocher les événements créant les notifications
Mettre la notification en léger décalé par cron ou refresh de page, évite de bloquer un peu la page pendant la validation (les notifications prennent du temps)
Je n'ai pas envie d'encombrer une liste de diffusion existante avec ça, ce ne sont pas des messages utiles à garder mais pourquoi pas une ML réservée (ou un flux en RSS) pour les notifications à ceux qui n'ont pas de xmpp/irc.
L'idée, c'est d'être averti quand quelque chose se passe sur le site sans devoir rafraîchir la page tout le temps (en plus d'une page illisible pour moi), c'est une perte de temps. Ça permettrait de réduire le temps de modération tout en ayant une vie à côté.
Le salon xmpp existant déjà, il manque un canal IRC quelque part. Tu peux en créer un et un compte IRC pour le robot. Je crée le compte sur robot sur xmpp. Puis tu testes http://outflux.net/software/pkgs/jirc-bridge/ chez toi par exemple quelque temps ?
Je propose un clic politique :
- Le clic de gauche pour y aller tout de suite
- Le clic du milieu pour y aller un peu plus tard
- Le clic de droite pour ne jamais y aller
Je l'utilise depuis quelques jours et il a fallu que je supprime les parties concernant git/svn/… car c'est beaucoup trop lent. Désormais c'est mieux mais ce n'est pas très réactif. J'ai ajouté l'affichage de l'horloge car ça me sert à savoir combien de temps peut prendre une tâche. Peut-être il y aurait moyen de mettre en cache certains résultats pour accélérer les calculs.
Il me semble que la machine actuelle a été fournie par l'hébergeur pour des raisons de consommation électrique et donc il refuseront d'héberger du matériel qu'ils ne connaissent pas. D'ailleurs, personne ne sait à qui appartient réellement la machine aujourd'hui, si c'est un don ou un hébergement sur un serveur prêté.
Souvent je me dis "où est-ce que je pourrais aller regarder pour avoir un bon exemple plutôt que de trop réfléchir ?" et donc là je me suis dit qu'aller regarder le plugin load de munin serait une bonne idée. En adaptant un peu pour prendre la première valeur moyenne cela donne :
[^] # Re: .
Posté par rootix . En réponse à la dépêche Première mise en demeure pour l'association LinuxFr. Évalué à 10.
j'ai pas bien saisi ce qui portait vraiment à préjudice
Ce qui lui porte préjudice (et c'est vrai), c'est le fait que les remarques (avec critiques argumentées) portent directement sur son cœur de métier. Donc un client potentiel qui verrait ces remarques pourraient douter des compétences de l'entreprise pour faire faire un site web par exemple. Cette entreprise ne savait pas que les lecteurs réguliers de linuxfr sont souvent à la pointe de la technologie (entre autre, grâce aux nombreuses news qui passent ici) et très compétents dans pleins de domaines. C'est effectivement un bon endroit pour recruter. Maintenant, j'imagine que c'est un peu embêtant pour avoir envie de postuler pour cette entreprise (et également pour être client). Après, la solution peut être un changement de nom pour la boîte ou une solution de dernière minute pour éviter l'effet Streisand. C'est en effet très difficile de réagir correctement en lisant des critiques très fortes et justifiées et je veux bien croire que la réaction émotive prend le dessus.
[^] # Re: En réponse à vos commentaires...
Posté par rootix . En réponse à la dépêche [JobCode 15 juin] 80 développeurs sélectionnés. Et toi, en feras-tu partie ?. Évalué à 5.
J'ai (en tant que modérateur) repensé à votre dépêche. Le problème, c'est qu'elle n'est pas assez vendeuse par rapport à l'attente que vous avez et pas assez "honnête" par rapport au fait que c'est une première pour vous. Le bon niveau technique "exigé" est difficile à demander car ça vous coupe d'une partie des plus compétents, je parle des perfectionnistes très bons mais qui ne se jugent pas assez "bons". C'est votre rôle de déterminer si le niveau est bon ou pas.
Les explications données dans les commentaires auraient dû être dans la dépêche dès le départ pour cette première fois. Je vous suggère de refaire une dépêche pour remplacer celle-ci en expliquant tout. On enlèvera celle-ci le moment venu.
[^] # Re: Ca commence très fort
Posté par rootix . En réponse à la dépêche [JobCode 15 juin] 80 développeurs sélectionnés. Et toi, en feras-tu partie ?. Évalué à 1.
J'avais vu l'erreur avant la modération et je savais que les 'www' ne marchaient pas. Mais quand j'ai vu l'exigence d'un bon niveau technique pour le concours, je me suis dit que laisser cette erreur, ça laisserait les lecteurs de linuxfr mesurer la hauteur de cette exigence.
Bon, je vais corriger. Je n'avais jamais vu une news notée à -2 ceci-dit.
[^] # Re: Modérateur, je veux bien !
Posté par rootix . En réponse à la dépêche Rejoignez LinuxFr.org ! LinuxFr.org c'est vous !. Évalué à 3.
Il faudrait dans un premier temps que tu participes régulièrement à la correction ou relecture des dépêches dans l'espace de rédaction collaborative. D'ici quelques semaines, tu pourrais poser éventuellement ta candidature ?
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 1 (+0/-0).
Le système donne la possibilité :
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0).
Je peux changer de mot : visibilité -> édition
Le conflit d'intérêt, on l'a actuellement en ce qui concerne les modérateurs qui rédigent beaucoup en partie rédaction et qui votent ensuite. Par principe, on pourrait bloquer le vote si le modérateur ou le rédacteur est l'auteur principal. Si on cherche à déterminer automatiquement si une édition est trop significative pour qu'un rédacteur ou modérateur ne puisse pas voter, on n'y arrive pas parce que c'est trop difficile à calculer.
C'est pour avoir un système souple et non rigide qui tienne compte de nos temps libres.
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0).
Afin d'avancer, je propose de créer un fil sur le mode de rédaction privé dans un autre ticket plus tard. L'objectif est de concentrer l'effort général sur la qualité de la rédaction et la vitesse de publication tout en ayant au moins 1 modération avant la publication.
Proposition n°3 :
[Rédaction]
Un seul espace de Rédaction (qui aurait une signification générale) visible de tous les utilisateurs sauf le contenu qui est fonction du rôle de l'utilisateur.
dépêches collaboratives :
dépêches en modération :
dépêches programmées :
[Journaux]
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0). Dernière modification le 01 mai 2013 à 23:08.
Proposition n°2 :
[Dépêches]
Ajout d'un champ pour choisir la date de publication
Note de Nÿco : voir ticket publication programmée
[Rédaction]
Un seul espace de Rédaction (qui aurait une signification générale) visible de tous les utilisateurs sauf le contenu qui est fonction du rôle de l'utilisateur.
dépêches privées :
dépêches collaboratives :
dépêches en modération :
dépêches programmées :
[Journaux]
[^] # Re: un mode brouillon pourrait correspondre à un mode privé
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0).
Je suggère de renommer le mode brouillon en mode privé :
J'ai proposé à Nyco de mettre un temps d'expiration (X jours) sur ce mode privé avant passage automatique en modération.
Peu avant la fin de l'expiration, un rappel est envoyé à l'auteur pour lui signaler que la dépêche va passer en modération. L'auteur peut éventuellement repousser la date en un clic s'il veut un peu plus de temps.
D'ailleurs, je pense qu'il pourrait vouloir inviter d'autres auteurs dans ce mode privé, ce qui apporterait l'avantage par rapport à un traitement de texte : mode de rédaction mais en privé avec des auteurs choisis, pour une préparation confidentielle.
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0).
Les Rédacteurs/Modérateurs sont complémentaires, l'un en priorité sur la Rédaction avec un pouvoir de vote et l'autre sur la Modération avec la possibilité de rédiger comme n'importe quel Rédacteur.
Il manque effectivement des détails dans mon schéma (je m'en rends compte après coup) mais si c'est sur la bonne piste, c'est pas mal.
Une fois que tout le monde s'accordera, on pourra demander le développement, qui va prendre peut-être du temps, et il faudra peut-être du renfort.
Je vais le corriger dans une autre réponse (je vais mettre un numéro au dessus pour pouvoir référencer la version).
[^] # Re: Pas de vote avant la modération
Posté par rootix . En réponse à l’entrée du suivi Amélioration du flux de rédaction/modération. Évalué à 2 (+0/-0). Dernière modification le 30 avril 2013 à 19:38.
Un seul espace de Rédaction (qui aurait une signification générale) visible de tous :
[Rédaction]
dépêches en brouillon :
dépêches en rédaction :
dépêches en finalisation/modération :
dépêches avec publication programmée à une date :
Autre chose :
Donner le droit aux rédacteurs de proposer un journal en dépêche
[^] # Re: Mes notes
Posté par rootix . 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 à 15:32.
Je soutiens le besoin du mode brouillon parce que tout le monde ne fonctionne pas de la même façon. L'auteur doit avoir le temps de travailler son texte comme il l'entend. Je suis sûr que ça pourrait motiver des personnes à au moins commencer quelque chose.
Je vois que tu as devancé l'élaboration de l'idée en améliorant la réflexion :
Au besoin de l'auteur, il pourrait demander à garder sa dépêche privée (case à cocher) pour que seuls les Rédacteurs (et modérateurs, admin) puissent la voir. Utile pour une information à ne pas diffuser tout de suite.
Donc c'est une ouverture générale à la Rédaction (et non plus nommée modération) sauf pour les dépêches "confidentielles".
Workflow :
En ce qui concerne l'affichage sur le site, il faudrait que chacun voit bien les tâches qui le concernent.
Au passage une fonctionnalité utile : publication à une date donnée
[^] # Re: Pas pour
Posté par rootix . En réponse à l’entrée du suivi Notifications xmpp. Évalué à 1 (+0/-0).
Je verrais bien 3 systèmes de notification réglables par option pour chaque modérateur/relecteur (et utilisateurs pour d'autres choses) :
- la couleur de fond de l'onglet qui change de couleur (comme sur un webmail) et un site qui rafraîchit correctement les choses en les rendant rapidement identifiables sans devoir dérouler la page
- une notification personnelle (sur option) sur le compte xmpp
- une notification personnelle (sur option) sur le compte mail
- cocher les événements créant les notifications
Mettre la notification en léger décalé par cron ou refresh de page, évite de bloquer un peu la page pendant la validation (les notifications prennent du temps)
[^] # Re: Pas pour
Posté par rootix . En réponse à l’entrée du suivi Notifications xmpp. Évalué à 2 (+0/-0).
Je n'ai pas envie d'encombrer une liste de diffusion existante avec ça, ce ne sont pas des messages utiles à garder mais pourquoi pas une ML réservée (ou un flux en RSS) pour les notifications à ceux qui n'ont pas de xmpp/irc.
L'idée, c'est d'être averti quand quelque chose se passe sur le site sans devoir rafraîchir la page tout le temps (en plus d'une page illisible pour moi), c'est une perte de temps. Ça permettrait de réduire le temps de modération tout en ayant une vie à côté.
# Canal IRC
Posté par rootix . En réponse à l’entrée du suivi Passerelle IRC/XMPP. Évalué à 2 (+0/-0).
Le salon xmpp existant déjà, il manque un canal IRC quelque part. Tu peux en créer un et un compte IRC pour le robot. Je crée le compte sur robot sur xmpp. Puis tu testes http://outflux.net/software/pkgs/jirc-bridge/ chez toi par exemple quelque temps ?
[^] # Re: Erreur sur le modèle du téléphone
Posté par rootix . En réponse à la dépêche FirefoxOS App Days : bilan d'un hackathon hautement politique. Évalué à 1.
J'ai corrigé l'article et mis un lien vers ton commentaire.
[^] # Re: GHC 4.7.2 ?
Posté par rootix . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 1.
Tes corrections n'avaient pas l'air d'être validées : j'ai changé les occurrences en 7.4.1 et le lien vers la bonne version de la documentation.
[^] # Re: GHC 4.7.2 ?
Posté par rootix . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 1.
D'après http://koji.fedoraproject.org/koji/packageinfo?packageID=1853 , ce serait 7.4.1 plutôt ?
[^] # Re: *Paf les yeux*
Posté par rootix . En réponse à la dépêche Le Parti de Gauche publie le code de son site sous licence libre. Évalué à 10.
Je propose un clic politique :
- Le clic de gauche pour y aller tout de suite
- Le clic du milieu pour y aller un peu plus tard
- Le clic de droite pour ne jamais y aller
[^] # Re: Développement ouvert ?
Posté par rootix . En réponse à la dépêche Ubuntu 12.10 « Quantal Quetzal ». Évalué à 5.
Peut-être regarder du côté de Linux Mint qui semble provoquer de plus en plus d'intérêts pour les déçus d'ubuntu.
# Un peu lent
Posté par rootix . En réponse à la dépêche LiquidPrompt version 1.0. Évalué à 4.
Je l'utilise depuis quelques jours et il a fallu que je supprime les parties concernant git/svn/… car c'est beaucoup trop lent. Désormais c'est mieux mais ce n'est pas très réactif. J'ai ajouté l'affichage de l'horloge car ça me sert à savoir combien de temps peut prendre une tâche. Peut-être il y aurait moyen de mettre en cache certains résultats pour accélérer les calculs.
[^] # Re: redis vs signature
Posté par rootix . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Il me semble que la machine actuelle a été fournie par l'hébergeur pour des raisons de consommation électrique et donc il refuseront d'héberger du matériel qu'ils ne connaissent pas. D'ailleurs, personne ne sait à qui appartient réellement la machine aujourd'hui, si c'est un don ou un hébergement sur un serveur prêté.
[^] # Re: uptime me renvoit mon load avec des virgule
Posté par rootix . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 2.
Souvent je me dis "où est-ce que je pourrais aller regarder pour avoir un bon exemple plutôt que de trop réfléchir ?" et donc là je me suis dit qu'aller regarder le plugin load de munin serait une bonne idée. En adaptant un peu pour prendre la première valeur moyenne cela donne :
[^] # Re: faut le comprendre comment ?
Posté par rootix . En réponse au message Futur infogérant. Évalué à 3.
[^] # Re: plus q'une semaine...
Posté par rootix . En réponse à la dépêche Les IDS et les obligations CNIL. Évalué à -2.
La minitel part à la poubelle le 30 juin : http://www.liberation.fr/depeches/2012/06/22/la-fin-du-minitel-prevue-au-30-juin-donne-du-travail-a-une-usine-de-traitement-des-dechets_828431