Adrien Dorsaz a écrit 954 commentaires

Il ne faut pas oublier que les emails ne sont pas synchronent: il peut y avoir beaucoup de délais entre l'envoi et la réception d'un email.

En plus, en général, il me semble que les fournisseurs de mail essaient pendant 5 jours d'envoyer l'email au serveur destinataire s'il est indisponible.

Du coup, si le serveur destinataire est indisponible pendant quelques temps (soit à cause du réseau IPv6 / IPv4 / BGP / VPN intermédiaire / firewall / DOS chez les intermédiaires / routeurs en rade…), c'est tout à fait possible que 3 heures ne suffisent simplement pas à recevoir un mail.

Je pense que garder 3 jours un compte inactif sur son service GIT n'est pas trop dérangeant (quelques Kio de disques employés) et permet au potentiel contributeur de terminer son inscription quand ses emails sont à nouveau disponible.

Si les disques se prennent vraiment trop de comptes ainsi à cause des bots, je descendrai la limite à 1 jour, voir 9 heures. En tout cas, je n'irai pas plus bas qu'"une journée de travail" (et encore, cette définition dépend des pays sources de contributeurs, par exemple, Suisse vs France vs Japon…).

Hello,

Une piste serait de ne plus employer Mono, mais directement .Net Core: c'est le nouveau moteur de Microsoft et il est open-source et compatible Linux nativement.

Je l'ai employé pour un petit PoC pour créer une API REST et Microsoft fournissait directement un répertoire APT pour installer .Net Core sur Ubuntu.

Je n'ai pas donc pas essayé de faire d'interface graphique avec ce moteur, mais ça doit sûrement être possible, car c'est le nouveau fer de lance de Microsoft et qu'il doit à terme remplacer Mono si je me souviens bien.

J'ai ajouté un exemple de documentation et j'ai corrigé la page "/admin/comptes" pour permettre d'enlever le rôle de mainteneur.

Pour les pages statiques (db/pages/aide.html et db/pages/team.html), j'ai mis à jour le texte uniquement dans le répertoire git. Il faudra ajouter à la main les paragraphes avec l'outil d'édition des pages.

Je n'ai pas voulu le faire automatiquement avec le système de migration, parce que je ne peux pas savoir si le code HTML dans la base de production correspond au code dans git.

Pour les statistiques, la jointure était déjà faite correctement avec la table "users" pour les "good_workers" (ça confirme que c'est donc une bonne idée de faire la correction du système de suivi).

J'ai donc juste modifié le titre de la statistique "Nombre d’entrées fermées par les administrateurs" pour finir avec "les mainteneurs et administrateurs".

modifier la page Les derniers comptes pour pouvoir changer le rôle ( ./app/views/admin/accounts/index.html.haml )

Pour ce point, j'y avais pensé et c'est déjà prêt :)

Merci pour le retour, je vais regarder pour ajouter le reste.

Super, merci pour la clôture et pour l'assignation :)

1) veux-tu être admin ?

Merci, mais je ne voudrais pas être admin, parce que ça active beaucoup trop de droits sur le site.

2) modifier le système pour choisir parmi les admins ou ceux ayant déjà eu un ticket attribué et un compte encore ouvert (ça résoudrait pas la première fois, juste les suivantes)

Ça c'est une idée intéressante, je vais regarder pour essayer de proposer une modification de ce genre.

Mais, si je ne me trompe pas, on pourrait aussi créer un rôle "mainteneur" qui ajoute juste la gestion du système de suivi à un utilisateur. Ça serait plus propre, mais je me demande si ça compliquerait trop la vie aux admins du site ?

Si je me souviens bien, rms avait vu ce problème de sémantique pour le terme "logiciel propriétaire" et il avait proposé "logiciel privateur [de libertés d'usage]".

Je pense que tu as raison et que " logiciel libre" a exactement le même problème de sémantique.

On pourrait l'appeler "logiciel libérateur [d'usage]".

Comme ça on a une sémantique cohérente pour les 2 opposés : logiciel privateur VS logiciel libérateur 😀

idle n'est pas un mot réservé au CPU, le nom va bien 😉

Pour le cas des contenus cachés, on pourrait utiliser la gem counter_culter qui permet de mettre à jour le cache aussi sur des mises à jour de valeur.

Hello !

J'ai trouvé la solution et j'ai proposé la modification ici: https://github.com/linuxfrorg/linuxfr.org/pull/289

Il est à noter que le compteur garde dans son compte les contenus "supprimés":

En effet, les contenus ne sont pas vraiment supprimés, mais uniquement cachés et du coup les méthodes de callback de counter_cache ne sont pas appelées.

D'un côté, ça serait logique d'enlever les contenus supprimés des compteurs, car ils ne sont plus accessibles.

Mais d'un autre côté, ça voudrait dire que l'on doit supprimer les tags au moment où on supprime le contenu et, du coup, on ne pourrait plus "restaurer" en l'état le contenu en changeant le flag node.public à true.

C'est la comparaison qui me fait rire, elle n'est pas honnête.

Je n'excuse ni les constructeurs, ni Google, ni ARM. Je relève les points qui font que ta comparaison me semble ridicule.

Tout à fait, les lois peuvent faire avancer les choses, mais en même temps, la loi a imposer la recharge par USB et Apple n'en avait rien à faire…

Ça me fait vraiment rire de comparer Apple qui a un parc déterminé et fini de SoC ARM et de firmware sur le marché et Google qui n'a aucune maîtrise des SoC et firmware et qui en a potentiellement un nombre de combinaison infini.

Si tu comparais Apple à Samsung, là j'aurai déjà mieux compris, mais ça ne va pas aussi: Samsung ne maîtrise pas du tout ce qu'il y aura dans les prochaines versions d'Android.

Si ARM standardise le démarrage du matériel et la découverte du matériel, ça aidera déjà beaucoup : il n'y aurai plus besoin de build un noyau custom juste pour son matériel… Ça marche très bien avec les "compatible PC".

Ensuite, Google devrait avoir un développement ouvert du projet AOSP et ne pas travailler en cachette pendant 1 an puis balancer les sources d'un coup. Ça doit être un travail de fou de reprendre leur OS complet chaque année et de tout tester sur son matériel. Bravo d'ailleurs aux contributeurs bde LineageOS pour ce travail !

Bref, Apple mène bien ses mises à jour, mais il maîtrise toute la chaîne du matériel à l'OS. Ils doivent juste faire attention à ne pas créer d'incompatibilités entre tout ça (jusqu'au jour où ils décident que les clients doivent repasser à la caisse, en rendant l'OS moins performant artificiellement sur les vieux périphériques).

C'est ça, ça va arriver, mais pas aussi vite que prévu.

Pour 2024, si j'étais à la place d'IdenTrust, je ferai la moue d'utiliser encore un certificat racine expiré (il est valide jusqu'en septembre 2021 théoriquement) pour créer de nouvelles signatures. En plus, ça pourrait réduire la confiance des systèmes dans leur gestion des certificats.

Par contre, je pense que le parc de téléphone Android aura déjà largement migrer vers des versions olus récentes que la 7.1.

Il y a un graphe sur Wikipedia si je me souviens bien qui montre l'évolution du parc, c'est assez intéressant.

C'est impressionnant comment le parc évolue vite. Je me dis qu'il doit y avoir beaucoup de gâchis de matériel à cause des techniques de ventes des constructeurs et de l'irrationalité des clients…

Wow, merci pour ces précisions, je n'avais jamais réfléchi à ces notions et là ça me paraît beaucoup plus claire !

Je pense d'ailleurs que je fais parti de ces utilisateurs qui ne comprennent pas tout 😅

Je comprends mieux pourquoi il y a un menu pour la taille de l'impression qui ne change rien à la visualisation de l'image sur l'écran, c'est tellement logique maintenant 😂 En plus, je pouvais ne voir aucune différence, même à l'impression si mon imprimante n'a pas un DPI assez élevé.

Ça serait peut être un bon endroit où on pourrait placer une petite aide à l'utilisateur pour l'éduquer un peu.

Bon, finalement, j'ai trouvé un peu de temps et de motivation pour voir comment faire des emails et des tâches automatique.

J'ai décrit un système de notification et de suppression automatique, dans un commentaire plus bas, je propose de continuer la discussion là-bas.

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

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

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

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

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

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

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

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

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

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

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

Je vais faire quelques tests ces prochains jours 😀

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

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

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

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

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

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

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

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

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

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

C’est bien vu et ça tombe bien, parce que j’ai proposé de mettre les textes suivants comme explication:

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

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

Est-ce que ça irait ou est-ce qu’il faut préciser « la tribune de rédaction ci-contre » ?

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

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

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

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

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

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

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

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

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

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

Est-ce que les textes te plaisent ?

Hello,

J'ai fait une entrée de suivi pour réduire par défaut la liste affichée aux dépêches actives dans les 3 derniers mois.

J'espère que ça permettrait de réduire le bruit pour les nouveaux rédacteurs motivés.

Une fois qu’une dépêche n’a pas été modifiée durant un certain temps (6 mois ? 1 an ?), elle serait disponible à l’adoption. Ainsi, si quelqu’un est motivé, il saura que la soumission de la dépêche dépendra de lui et pas d’un auteur qui ne passe peut-être même plus sur LinuxFR.

Je ne l'ai pas fait, mais je me dis que l'on peut déjà "adopter une dépêche": il faut aller dans la tribune de la dépêche et demander à la modération soit de démarrer la publication, soit demander la paternité de la dépêche (par exemple, si la moitié a été modifiée :-)).

Hello,

Pour moi, cette dépêche est très bien: elle parle d'un sujet autour du libre et, en plus, nous fait découvrir un petit projet très intéressant.

On découvre d'ailleurs régulièrement passer ce bandeau sur la page d'accueil:

Faites vivre LinuxFr.org

Tous les articles sont le fruit du travail de la communauté. Grâce au système de rédaction coopérative du site, on peut s’aider les uns les autres. Pas besoin d’expertise pour participer.

C'est des nouvelles faites par la communauté et pour la communauté, nous n'avons pas de vocation à faire des articles totalement objectifs et de qualité journalistique 😉

Pour plus d'informations, voire la page à propos.

Un début d'explication est donné à la fin de l'annonce à propos de la future version 1.0: un des auteurs avait eu un nouveau poste de recherche académique qui l'empêchait de mener tout projet de recherche en dehors du travail (ou en tout cas qui poserait des questions juridiques).