Benoît Sibaud a écrit 8961 commentaires

On a largement dépassé les trois comptes mastodon renseignés, désormais.
Le maximum est de deux sur la même instance, actuellement.
Le suspense est à son comble.

• en tant que membre de l’équipe LinuxFr.org : le code en lui-même n’est pas versionné (autrement qu’être une succession de commits datés), ils sont annoncés dans les rétrospectives de la quinzaine mais sans effort particulier de vulgarisation, et parfois une dépêche vient décrire les nouveautés (il y en a une en rédaction par exemple).
• en tant que développeur, sur du code partagé mis à la disposition d’autres personnes (par exemple des rôles ansible communautaires) : quasi chaque commit donne lieu à une version, et donc je décris à chaque fois le changement (et l’étiquette x.y.z sur le commit permet aussi de savoir à quel point on a cassé la rétrocompatibilité). Mais je ne m’astreins pas à avoir en plus un fichier Changelog dans le dépôt.
• en tant que admin sys, avant de faire des mises à jour liées à du fonctionnel (ie. pas juste des mises à jour de sécurité, confiées aux équipes de la distribution par exemple), alors je parcours les notes de version notamment pour voir des ruptures de compatibilité éventuelles, ou des annonces de fonctions obsolètes ou en voie de l’être, ou des changements de configuration, ou même des nouvelles fonctionnalités qui pourraient m’intéresser. Souvent une lecture rapide en diagonale, parce que toute façon il est peu probable que je comprenne chaque ligne individuellement, sauf à connaître sur le bout des doigts le logiciel en question, et encore…
• en tant que simple utilisateur : ça dépend, je lis les notes de versions pour les montées de distribution Debian par exemple, j’essaie de lire les notes de versions de chaque application sur mobile (mais souvent c’est plus que sommaire « on a corrigé des trucs » et « on a amélioré les perfs ») mais c’est tellement fréquent…

En parlant de chiffres, peut-être un jour aura-t-on quelque chose dans la nouvelle partie « Domaine Mastodon » des « Statistiques sur les utilisatrices et utilisateurs », mais bon il faudrait plus de trois comptes Mastodon sur le même domaine… il faudrait plus de trois comptes Mastodon déjà… Suspense.

Tu parles des 3 qui ont déjà écrit une dépêche cette année ? Ça n'est pas vraiment lié à la modération, plus à leur activité globale sur le le site.

Parce que sinon il y a plus de 3 personnes qui ont voté sur les dépêches en modération, édité ces dépêches ou publié ces dépêches en janvier 2023 (bref qui ont été actives suivant ces statistiques imparfaites).

8e circo Français établis à l'étranger
https://webview.conseil-constitutionnel.fr/actualites/communique/decision-n-2022-5773-an-du-3-fevrier-2023-communique-de-presse
il a pu irrégulièrement être proposé aux électeurs de voter par internet à leur place en utilisant leurs identifiants et mots de passe.

La page « équipe » pourrait donc préciser que les administrateurs sont également modérateurs. Par exemple « L’actuelle équipe de modération est composée des administrateurs et de : […] ».

Oui.

sur LinuxFr le directeur de publication peut-il publier directement une dépêche (quand bien même ce serait exceptionnel) ?

Les admins du site ont une fonctionnalité 49.3 pour publier ou rejeter n'importe quelle dépêche en modération, sans avoir besoin des votes habituels. Et le directeur de publication est admin du site.

(Précisions sans grande importance dans le débat en cours)

À noter qu’il existe également une distinction entre l’association LinuxFr.org et l’équipe de modération sont deux choses différente.

L'association se nomme Linuxfr, et donne une entité légale au site, pour le compte bancaire et la responsabilité.

Ni le président, ni le vice président, ni le trésorier ne sont actuellement membres de l’équipe de modération il me semble, et je n’ai pas l’impression qu’un membre de l’actuelle équipe de modération soit membre de l’association (ou s’il y en a, ils sont minoritaires).

Les admins du site font partie de l'équipe de modération. Le président de l'association et le trésorier et divers autres membres de l'association en font partie. Ils sont probablement majoritaires d'ailleurs. Et un mini effet dans la modération via la règle cas limite Si trois personnes ou plus, comprenant au moins deux membres de l’association LinuxFr, se sont toutes exprimées pour la même décision, elle est considérée comme adoptée. (source https://linuxfr.org/regles_de_moderation_du_problematique
)

Par contre le directeur de publication est actuellement président de l’association, c’est peut-être une nécessité légale d’ailleurs.

Pas une nécessité légale (c'est le choix par défaut par contre). Il n'est pas obligatoire de faire reposer la responsabilité de l'association et celle des contenus du site sur la même personne.

Chronophage de répondre aux questions ? D'une part ça montre un intérêt, sur des tâches qui pourraient être faites dans l'indifférence complète, donc on ne va pas se plaindre d'avoir des questions :). C'est même plutôt bon pour la motivation je dirais. D'autre part ça aide à préparer la suite en réfléchissant au sujet et en mettant par écrit, pédagogiquement si possible. Plus d'autres aspects comme le fait de pouvoir partager avec d'autres personnes de l'équipe qui débuteraient ou connaîtraient moins le sujet, ou bien le fait que même tout seul je peux retrouver un vieux commentaire à moi et comprendre/redécouvrir ce que j'avais fait, quels étaient les chiffres de l'époque, etc.

10 ans c'est probablement trop long vu notre nécessité/besoin et ce que demande le RGPD. On n'a certes pas de données hypersensibles, mais pas grand chose ne justifie de les garder super longtemps non plus. Six ou sept ans serait un max a priori. Mais pour LinuxFr il faudrait plutôt choisir entre 1 an ou 3 ans ou 5 ans.

Mon idée serait de lancer une dépêche sous peu indiquant les changements envisagés, et de les appliquer à partir de la date anniversaire des 25 ans du site (fin juin donc), ce qui laisserait le temps aux gens qui le souhaitent de réagir, utiliser leur compte, fermer leur compte, etc.

C'est ce que je décris dans mon dernière paragraphe notamment. Actuellement, non, rien n'est fait automagiquement.

(pour les contenus en base de données mariadb ou redis, hors fichiers d'images, caches, logs, etc)

avant le nettoyage :

ls -l --si
-rw------- 1 root root 2,0G janv. 29 05:27 mariadb.dump.gz
-rw------- 1 root root  20M janv. 29 05:27 redis.rdb.gz

après le nettoyage :

-rw------- 1 root root 1,9G janv. 30 03:25 mariadb.dump.gz
-rw------- 1 root root  20M janv. 30 03:25 redis.rdb.gz

(8,9 GiB pour mariadb.dump hors compression gzip)

data_length + index_length : 12.85 GiB selon MariaDB

+----------------------+------------+---------+
| Table                | Size (MiB) | Rows    |
+----------------------+------------+---------+
| news_versions        |    8969.06 |  383245 |
| comments             |    3219.47 | 1888308 |
| diaries              |     271.13 |   39730 |
| paragraphs           |     190.19 |  220226 |
| news                 |     169.41 |   27263 |
| posts                |     165.66 |   39876 |
| friendly_id_slugs    |      29.11 |  181798 |
| nodes                |      27.13 |  115099 |
| wiki_versions        |      26.66 |    2201 |
| taggings             |      26.50 |  154177 |
| accounts             |      18.13 |   33400 |
| oauth_access_tokens  |      14.52 |    7473 |
| links                |      12.03 |   85217 |
| trackers             |       5.83 |    1987 |
| users                |       5.03 |   53852 |
| wiki_pages           |       2.53 |     154 |
| tags                 |       2.30 |   14096 |
| bookmarks            |       2.03 |    5625 |
| logs                 |       1.78 |   12028 |
| oauth_access_grants  |       0.56 |    1576 |
| poll_answers         |       0.47 |    4080 |
| polls                |       0.31 |     469 |
| pages                |       0.17 |      13 |
| oauth_applications   |       0.05 |      20 |
| sections             |       0.05 |      99 |
| forums               |       0.03 |      39 |
| friend_sites         |       0.03 |      13 |
| banners              |       0.02 |      14 |
| responses            |       0.02 |      12 |
| schema_migrations    |       0.02 |      74 |
| categories           |       0.02 |      31 |
+----------------------+------------+---------+

Chaque rétrospective de quinzaine (exemple) indique les commentaires et contenus masqués :

1472 commentaires publiés (dont 3 masqués depuis) ;
778 étiquettes posées ;
63 comptes ouverts (dont 16 fermés depuis) ;
45 entrées de forum publiées (dont 5 masquées depuis) ;
98 liens publiés (dont 2 masqués depuis) ;
19 dépêches publiées ;
17 journaux publiés (dont 1 masqué depuis) ;
1 entrée nouvelle, 1 corrigée et 0 invalide dans le système de suivi ;
1 sondage publié ;
0 page wiki publiée (dont 0 masquée depuis).

Les comptes non confirmés (validation du lien reçu par courriel) / jamais utilisés sont supprimés automatiquement.
Les comptes fermés le sont soit par les personnes ayant les comptes, soit par les admins (spam de très loin en premier, abus, illégalité manifeste, demande des personnes ayant les comptes, etc.). Ils restent en base.
Les contenus (dépêches, journaux, forums, sondages, pages wiki, suivi, liens) et les commentaires peuvent être masqués/dépubliés par les admins (spam, abus, illégalité manifeste, demande des personnes pour virer un doublon ou retirer un propos, purge de compte demandée, etc.). À part dans le cas de la purge, qui a lieu en base, les contenus et commentaires dépubliés restent en base.
Les étiquettes peuvent être masquées par les admins (mauvais nom, doublon, spam, etc.). Ces étiquettes restent en base.

L'opération de ce ticket consistait à supprimer ce qui était invisible sauf pour les admins, et qui avait plus d'un an, pour alléger la base, pour virer l'inutile. Pourquoi garder un an ? Pour avoir un peu de recul sur les spammeurs et les problèmes passés au besoin, pour republier au besoin ce qui aurait été dépublié par erreur / à tort, etc.

L'effacement automatique au bout d'un an de l'invisible serait à implémenter.
Et les questions plus compliquées/longues arrivent ensuite :

• mettre en place une fermeture des comptes inactifs après une durée (règle à définir, communiquer et implémenter). Objectifs: minimisation des données personnelles conservées, alléger la base
• mettre en place une suppression des comptes fermés après une durée (règle à définir, communiquer et implémenter). Objectifs: minimisation des données personnelles conservées, alléger la base :
  • associés à aucun contenu/commentaire public : cas facile
  • associés à un ou plus contenu/commentaire public : arbitrage minimisation des données personnelles (RGPD) et droit d'auteur (conserver le pseudo ou nom de la personne)
• définir pour chaque donnée personnelle ce qui arrive suivant les cas

wiki_pages (0.51 sec)
nodes (9.01 sec)
friendly_id_slugs (6.10 sec)
wiki_versions (1.41 sec)
comments (19 min 30.00 sec)
trackers (0.70 sec)
polls (0.35 sec)
poll_answers (0.35 sec)
posts (15.73 sec)
diaries (26.85 sec)
bookmarks (0.51 sec)
news (19.61 sec)
news_versions (17 min 59.50 sec)
paragraphs (30.03 sec)
links (2.30 sec)

Les titre et corps des commentaires de plus d'un an ont été purgés (ce qui ne change rien en apparence pour tous ceux qui ne sont pas dans l'administration du site, mais qui allège la base de données). 14338 commentaires concernés.

Supprimer les contenus non publics datant de plus d'un an (et les étiquetages associés s'il y en a, et les commentaires associés s'il y en a)

• 139 pages wiki non publiques supprimées (datant de mai 2012 à avril 2020) -> 139 tuples de wiki_pages, 139 de nodes, 139 de friendly_id_slugs, 247 de wiki_versions et 26 de comments
• 40 entrées de suivi non publiques (datant de juillet 2021 à octobre 2019) -> 40 tuples de trackers, 40 de nodes, 64 de friendly_id_slugs et 10 de comments
• 106 sondages non publics et hors modération (date d'avril 2012 à juillet 2021) -> 106 tuples de polls, 106 de nodes, 110 de friendly_id_slugs, 662 de poll_answers et 2 de comments
• 894 entrées de forums non publiques (jusqu'au 28 janvier 2022)-> 894 posts, 894 nodes, 933 friendly_id_slugs, 382 comments
• 171 journaux non publics (jusqu'au 28 janvier 2022)-> 171 diaries, 171 nodes, 172 friendly_id_slugs, 1509 comments
• 170 liens non publics (jusqu'au 28 janvier 2022) -> 170 bookmarks, 170 nodes, 170 friendly_id_slugs et 61 comments
• 1627 dépêches non publiques rejetées ou supprimées (jusqu'au 28 janvier 2022) -> 1627 news, 1627 nodes, 2250 friendly_id_slugs, 18509 news_versions, 15468 paragraphs, 1952 links

Fusionné https://github.com/linuxfrorg/linuxfr.org/commit/80fb5c8aad994efc45b287e7717ed52e073a98fb et déployé

Merci

Fusionné et déployé https://github.com/linuxfrorg/linuxfr.org/commit/368abcf2ab3f998ca0c13b01fc628d7cec742c52

Merci.

Fusionné et déployé, et merci à Trim.

La réponse est dans ces deux lignes :

IPT=$(which iptables)
IPTMO="$IPT -t mangle -A POSTROUTING"

Que vaut la variable IPT et pourquoi ? Que vaut la variable IPTMO et pourquoi ?

Les chiffres disent :

Type	Juin	Juillet	Commentaire
Markdown	6726	7738	les 598 corrigées + 14 nouvelles dépêches
HTML	15570	15570	pas de changement
Bizarre 1	598	0	retour à du Markdown normal
Bizarre 2	3613	3613	pas de changement

Micro-correction après la fusion, concernant les cas où l'identifiant du compte est différent du slug :

https://github.com/linuxfrorg/linuxfr.org/commit/983e8b81f5717417380eeb304b01e4b1c628419b

Et les ajouts liés à la partie administration (avec un peu de rattrapage sur les autres adresses associées à un compte, au passage) :

https://github.com/linuxfrorg/linuxfr.org/pull/360

(tout est déployé sur le serveur de test actuellement)

Il n'y a pas de 's' en bon français à deux vingt deux, car les multiples de vingt ne prendent pas de 's' quand ils sont suivi.

Le temps, ie. des gens ont écrit des dépêches supplémentaires ?

Il me paraît important de séparer la partie génération de texte, qui fait ce pour quoi elle est faite, sans surprise, générer un texte probable dans le contexte fourni, de la partie chatbot qui discute et produit le contexte à donner au générateur.

Le générateur me paraît juste impressionnant par sa "taille", il a eu un vaste corpus de textes, utilise masse de paramètres, blabla. Mais rien de révolutionnaire si j'ai bien suivi, en dehors de la volumétrie.

La partie chatbot fait la différence je trouve. Techniquement j'entends. Et elle amène plein de problèmes éthiques en cachant le fait que c'est une façade pour un générateur et pas pour un cerveau synthétique qui comprend et répond à la question posée… c'est pernicieux, et trompeur même en le sachant.

Ouf, personne n'a encore demandé la liste des personnes qui n'ont pas noté, ou pire qui n'ont pas lu.