Sujet sur Discussion utilisateur:Lofhi/Structured Discussions Archive 1

Lofhi, comme tous les ans depuis quelques années, le mois du sourçage commence le 1er janvier 2024, sur tout le mois. Est-il possible de créer une page spécifique à 2024 ? de mettre à jour les statistiques ? et les outils constituant un retour d'information vers les participants ? D'avance merci.

Tiens, ce n'est plus Jules qui s'en occupe ? 😉 Assurément, je le peux. J'ai en tête depuis un moment de transformer mon script bâtard en un site communautaire léger hébergé par la fondation et qui permettrait d'organiser ce genre de campagne plus facilement et en toute indépendance, mais je ne promets pas que cela sera le cas pour le prochain mois du sourçage.

Lofthi, @Jules* est partout, vous savez bien. Je suis peut-être même un de ses pseudos, qui sait {{Smirc|cool}} ... Pérenniser ces outils et les rendre indépendant de leur créateur me semble une très bonne orientation. Le mode de fonctionnement actuel est très personnalisé.Il manque juste une page où chaque participant à ce type d'opération pourrait mentionner, à sa convenance, ses réalisations qu'il juge les plus marquantes. En fait, je vous sollicite dès fin novembre/début décembre, soit un mois avant le début de cette opération, parce que 1) je voudrais l'annoncer et rappeler son existence en décembre, que les contributeurs intéressés s'organisent pour y participer, 2) parce que dans les deux dernières éditions, les participants n'avaient aucune information, pendant quelques jours, au démarrrage sur leurs apports. Merci de vos apports

Des faux-nez ! Je pensais à complètement séparer l'outil de l'initiative : les statistiques ne seraient plus afficher sur la page de l’événement mais sur un site communautaire hébergé sur Toolforge (plateforme d'hébergement gratuite de la fondation) ; un peu comme PetScan. Vu que cela n'a jamais été un concours, il n'y aucune raison d'afficher constamment les avancées et en général les contributeurs sont plutôt intéressés par le total final. Aussi, cela serait plus simple d'avoir la liste des articles retravaillés et plus facilement personnalisable aux besoins généraux.

Je dois juste prendre le temps d'y travailler, je voudrai que cela soit un site extrêmement léger et facilement maintenable dans le cas où je me fasse écraser. Typiquement, ne pas avoir de base de données à gérer par exemple, comme PetScan (c'est à moitié vrai, mais je veux m'inspirer des liens partageables).

Il y a déjà un site communautaire plus ou moins proche du concept nommé Fountain pour les editathons, mais impossible de chercher un mot-clé.

@Jules*, je suis en train de discuter avec des volontaires sur IRC pour mettre en place ce que je conceptualise. Nouvelle approche en tête.

Est-ce que les administrateurs voient d'un mauvais œil la création de tags temporaires (ou pas) pour des événements comme celui-ci ? Je n'ai pas vérifié l'hypothèse, mais sur le papier le tag étant très facilement discriminant pour les bases de données derrière Wikipédia, il serait beaucoup plus rapide de récupérer les modifications taguées spécifiquement pour un événement que de chercher un mot dans les commentaires des révisions (le #hashtag). L'idée qui me vient serait de créer un gadget qui ajouterait le tag quand il est activé manuellement par le contributeur en plus du site communautaire pour l'aspect visualisation des articles.

Sinon, je peux fouiller toutes les révisions, mais les requêtes peuvent être très longues (même si raisonnable après vérification : moins d'une minute pour fouiller les modifications sur une année).

Hello Lofhi. Merci de gérer ça ! Par tag, tu veux dire balise ? Ou alors c'est une autre fonctionnalité que je ne connais pas ?

Oui, pardon, balise.

J'ignore ce qu'en penseraient les autres admins (95 % d'entre eux ne savent vraisemblablement pas ce qu'est une balise), mais je pense que c'est tout à fait OK de gérer ça avec des balises éphémères. Je ping LD qui aura peut-être un éclairage technique supplémentaire.

Okidoki, après peut-être pas besoin d'une balise par événement. Vu la quantité des modifications par année lors de ces mois spéciaux, cela reste très minoritaire (et donc discriminant) face en moyenne aux 20 000 modifications par jour sur frwiki. Tout mettre sous une même balise à chaque fois devrait largement suffire !

PS : c'est quoi le nom déjà de l'outil qui permet de chercher un mot dans les contributions d'un contributeur ? J'ai oublié.

J'ai peur que ces réflexions ne soient plus compatibles avec un mois du sourçage qui commence dans un mois, et qu'il faut commencer à annoncer. Pourrait-on avec l'évolution minimale qui permette l'édition 2024, puis faire réagir les contributeurs de cette édition 2024 sur un outil pérenne ? Peut-être tester quelques évolutions pendant cette édition mais ne pas tout bouleverser ?

En vrai, avec un peu de motivation, c'est tout à fait compatible, mais si la question est : est-ce que je peux juste lancer l'ancien script pour le mois spécial de janvier, oui aussi !

https://sigma.toolforge.org/summary.py?name=Toto&search=%23moisantipub&max=100&server=frwiki&ns=None ;)

Salut,

Mes quelques recommandations pour le site :

• Avoir des co-"admins" du projet sur Toolforge : essentiellement en cas de reboot, mise à jour des librairies, etc.
• Mettre le code sur GitHub afin que le projet soit plus simple à réviser et maintenir.
• Je pense qu'il vaut mieux éviter de s'orienter vers des bases de données car cela implique de prendre en compte des aspects sécuritaires (éviter des injections SQL par exemple).
• Personnellement, j'aime bien avoir un .json en local (exemple) s'il y a des requêtes POST pour mettre à jour une page. Cela évite de devoir bloquer le compte qui édite en cas de bug ou autres. JSON fait partie du core de PHP 8.0, c'est compatible avec Python et pas mal d'autres langages (facile avec le raw)

Ce qui m'amène à dire que j'ignore sur quel langage tu t'orienterais ; s'il y a des besoins en PHP, je peux toujours y jeter un oeil. Vu que Python semble ton langage de coeur, tu peux toujours regarder le wikitech Django ^^. Je n'ai pas encore pris le temps de fouiller Toolforge, même si j'ai un compte outillé (là-dessus, il ne faut pas trop compter sur moi ^^).

Pour les balises, les admins n'ont trop rien à dire à mon avis (même si la gestion leur est confiée) : les autopatrolled ont déjà le droit d'« ajouter et supprimer de façon arbitraire des balises sur des versions individuelles et des entrées de journal » et les users peuvent en ajouter sur leurs propres révisions. Temporaires ou non, je ne crois pas que ce soit un obstacle. Cela dit, j'éviterai de mélanger toutes les modifs (d'évènements différents) sous un même balise.

Si côté utilisateur tu veux simplifier l'ajout d'une balise, un javascript fait l'affaire (d'autres le font déjà : LiveRC, Adiutor, etc.) : une case à cocher près d'enregistrer (?).

Ça en fait des mots ! Merci pour les détails. J'ai eu le temps de masser mon cerveau lisse depuis mon dernier message. Qu'en est-il de ne pas utiliser de gadget, mais un filtre qui appliquerait automatiquement une balise à un changement si le mot-clé est détecté dans le commentaire d'édition ?

Grande facilité d'utilisation, on ne change pas les habitudes (hashtag conservé). Le problème, c'est la charge même minime ajoutée côté serveur à chaque édition avec ce nouveau filtre. Pas convaincu, ce n'est pas très séduisant.

La seule alternative que je vois sans changer le fonctionnement actuel des mois spéciaux, c'est à la rigueur d'avoir un monitoring externe d'une manière à spécifier. Cela peut-être un bot qui vérifie régulièrement les changements récents pour appliquer les balises. À voir s'il est automatique ou lancer manuellement par les contributeurs. Même l'idée de créer un gadget est une contrainte fonctionnelle : imaginez un nouveau contributeur qui doit activer un gadget pour facilement lister ses modifications. C'est hyper lourd, là où actuellement il n'a pas besoin de grand chose que se rappeler d'écrire le hashtag.

Par contre, avantage des balises, si le hashtag est oublié... On s'en fiche. Il peut-être ajouté ou retiré facilement sur la modification. Il y a une marge de manœuvre pour les erreurs éditoriales.

Pour référence, les statistiques autour d'AbuseFilter : https://grafana.wikimedia.org/d/000000393/mediawiki-abusefilter-profiling?var-wiki=frwiki&var-metric=p95

J'ai fini une première version stable de l'outil, mais je ne pourrai pas le déployer avant la semaine prochaine. Un nouveau workflow sur Toolforge que je dois prendre en main. Cela ne devrait pas être trop compliqué après quelques discussions avec des dévs de la fondation.

A en croire les tâches Phabricator, il faut regarder du côté de Kubernetes (Jobs, en particulier la section Grid Engine migration).

Ils ont un tout nouveau Build Service surtout !

Je viens de regarder vite fait car j'aimerais bien lancer Taxobot sur toolforge, et malgré les docs, j'ai rien compris à lighttpd (je le fais tourner en apache ). Si tu as des infos, je prends ;)

Si ce n'est pas urgent, je regarderai la semaine prochaine. J'ai moi-même rencontré de nouveaux problèmes... Phab:T353557.

Pas du tout urgent ;)

@LD est déjà au courant, mais j'ai presque fini le déploiement : https://hitaden.toolforge.org/

Je me cite « Ton site est tout beau tout propre », ça vaut le détour

Finito, le service est en ligne. Bonnes fêtes !