Le nombre d’avis quotidiens est déterminé à partir du karma. La formule est max(0, min(3 + karma/10, 100)) (source).
Le score de base des commentaires dépend du karma. La formule est E(log10(karma)) - 1, où E() est la partie entière inférieure si le karma est strictement positif. Et c’est max(-10, -2 + E(karma/30)) pour un karma négatif ou nul. Avec un karma à 0, ça donne un score de -2 (source).
| Karma | Score de base des commentaires |
|---|---|
| -240 ou moins |
L'idée serait de :
Notamment pour le nouveau lectorat (et les personnes totalement externes au site).
Cf https://linuxfr.org/users/arnaudus/journaux/publication-du-stallman-report-2024#comment-1978221
Notre zone DNS était gérée par TuxFamily. Le 10 décembre 2024, un incident DNS touchait les deux serveurs DNS de TuxFamily (et rendait tous leurs services inaccessibles, donc leur serveur IRC et leur site web pour avoir des infos sur la durée de la coupure).
Une bascule de DNS a été faite à 08:38 Paris pour ré-héberger la zone ailleurs (pratique d'avoir une copie de la zone sous la main) et redevenir accessible.
Les DNS TuxFamily sont ensuite revenus en (…)
Si une dépêche contient un sommaire et que l'un des titres contient un lien, alors le début du titre dans le sommaire est un lien vers la sous-section de la dépêche, la suite est le lien présent initialement dans le titre et la fin est sans lien.
Ainsi :
#A[B](https://localhost.invalid)C[D](https://localhost.invalid)E<a href="#toc-abcde">A</a><a href="https://localhost.invalid">B</a>C<a href="https://localhost.invalid">D</aLa suite de tests actuelle "couvre" le cas des images de plus de 5 MiB ou non récupérables : on a des tests qui échouent, comme prévus, vu que c'est "img" qui est censé faire le job de les éviter.
Cependant il pourrait être sympa de remplacer toute image non dispo/invalide par une image fictive "Image indisponible" du bon Content-Type et du bon nom (vu qu'elle est déclarée dans le MANIFEST).
Cas de l'image de plus de 5 MiB :
(…)Finaliser la synthèse en cours d’écriture sur le karma
Les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent.
Scénario à vérifier :
img réponde HTTP 404 sur la demande d'image (au lieu de juste servir l'image en cache en attendant que les choses aillent mieux côté serveur initial)De manière générale, les 5xx ne devraient pas interférer avec la disponibilité de (…)
Dans la famille « Retirer les liens » je voudrais goo.gl.
https://developers.googleblog.com/en/google-url-shortener-links-will-no-longer-be-available/
Actuellement les tribunes de modération des dépêches sont conservées à l'infini.
Une fois publiée, l'intérêt de conserver les échanges rédaction/modération diminue grandement avec le temps.
Elles peuvent permettre de dater les changements et expliquer les choix effectués, servir en cas de litige (droit d'auteur, diffamation, etc.) mais c'est sans intérêt une fois passée la prescription (et c'est la version publiée qui serait attaquée pas une version précédente).
Quelles règles pour nettoyer les tribunes de modération de dépêches ?
Actuellement les différentes versions des dépêches publiées sont conservées à l'infini, ainsi que chaque tribune de modération par dépêche.
La table SQL pour les versions de dépêches est la plus grosse pour le site (405358 versions pour 12425 dépêches) :
+---------------+------------+
| Table | Size in MB |
+---------------+------------+
| news_versions | 9458.06 |
+---------------+------------+
Utilisation :
Une sorte de meta-entrée de suivi pour discuter des soucis sur les images (domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing) sont en augmentation (imageshack.us, après framapic, pix.toilelibre, etc.).
ça arrive de plus en plus en souvent et ce n'est pas prêt de s'arrêter. Que mettre en place techniquement pour gérer ça ?
Liste probablement non exhaustive d'entrées de suivi sur le sujet :
Une sorte de meta-entrée de suivi pour discuter des soucis sur les liens (domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing) sont en augmentation (après mandriva, in libro veritas, oreilly fr, linux-france…).
ça arrive de plus en plus en souvent et ce n'est pas prêt de s'arrêter. Que mettre en place techniquement pour gérer ça ?
Liste probablement non exhaustive d'entrées de suivi sur le sujet :
Sur le nofollow, noindex, https://linuxfr.org/nodes/135534/comments/1957102 à mettre dans l'aide du site en ajoutant que la mise à jour du karma est quotidienne https://github.com/linuxfrorg/linuxfr.org/blob/master/lib/tasks/linuxfr.rake donc entraîne un décalage (tandis que les notes sont mises à jour immédiatement)