Wikipédia:GTA-SF

Great Tool for Admins and Serious Fighters

Ehh, non, ça ne parle pas de jeu :)

But

Améliorer l'efficacité des patrouilles RC en limitant les collisions, en permettant de savoir s'il y a quelqu'un d'autres sur les RC et en favorisant le travail d'équipe.

Archi

• Architecture client-serveur:
  • Le serveur IRC qui distribue les diffs
  • Le serveur GTA-SF qui assure le partage du savoir des actions de chacun
  • Le client chez chaque utilisateur

Utilisation/Fonctionnalités

Au démarrage d'une session, la personne se loggue au moyen d'un mot de passe qui lui donne accès au système (pour éviter que des IP valident des édits). Le client récupère la liste des patrouilleurs en ligne et charge une liste d'ignorés qui permet à chacun de ne pas tenir compte des actions de certaines personnes (en qui elles ont, par leur jeunesse ou leurs habitudes, peu confiance).

Après choix du canal (IP, user, newbie, all) et appui sur le bouton de connexion, connexion au serveur IRC et affichage des diff demandés, avec cumul des diffs de l'éditeur courant lors de l'affichage de chaque diff, si les précédents n'ont pas été validés. Pour mieux se répartir les tâches, on peut également choisir une inclination: révoquer ou avertir/bloquer, ce qui permet de travailler à deux sur les mêmes vandalismes.

L'appui sur une action (valider, enquêter, révoquer, avertir -plusieurs niveaux-, bloquer) fait une requête au serveur. Si une action est déjà en cours par un non-ignoré, celle-ci s'affiche de couleur. Il est alors possible d'aller au-delà, après un petit message d'avertissement. Il peut arriver que la couleur n'est pas eu le temps de venir, mais le message viendra de même, le temps pour le paquet de faire l'aller-retour vers le serveur. La personne dont l'action était en cours en est averti (pratique notamment si elle était en enquête et que l'autre savait déjà).

Les édits non validés sont sur fond de couleur, les édit révertés au contributeur non averti/non bloqué sont d'une autre couleur et les édits non-validé de personnes avertis sur une autre encore.

Les édits révoqués disparaissent après une poignée de secondes (le temps de laisser le temps de demander l'avertissement et le blocage).

Enfin, une black-list permet de mettre en valeur les contributions de certains utilisateurs.

A priori, pour procéder aux révocations et blocage, il sera nécessaire de passer par l'ouverture d'une page dans un browser (sauf à faire une fausse révocation à la main, ce qui pourrait être pratique pour les non-admin).

Un petit chat peut être affiché en bas de l'écran.

On peut prévenir de son départ prochain (ce qui permet de se répartir vaguement le temps, en faisant une pause, par exemple).

Pour aider à la décision, un système de popup (comme il existe pour prévisualiser les liens wur WP) montrant un aperçu de la page de discussions, de la liste de contrib et des contribs d'un éditeur serait sympa.

Résumé

• Cercle de confiance
• Filtrage IP/User/Newbies (Special:Contributions/newbies)
• Mise en valeur Validé/Averti/Blacklisté/blocké/déjà bloqué auparavant/IP d'établissement
• Affichage cumulé des diffs
• Chat
• Découpage du travail en 2 parties (révoquer, punir) pour parallélisation
• Vérification de marchage sur les pied avec possibilité de passer outre
• Système de popup de collecte d'info: liste de contrib de l'utilisateur, preview de ses diffs, de sa page de discussion.
• Évaluation heuristique de la probabilité de vandalisme

Propositions d'implémentation

Proposition 1

Je propose d'implémenter cet outil collaboratif avec Ruby on Rails.

Avantages

• facilité pour écrire le code
• pas de clients et donc différentes versions d'un outil à gérer
• intégration directe dans le browser (très simple à utiliser avec les tabs de Firefox)

Inconvénients

• synchronisation problématique qui ne peut qu'être obtenue par un refresh

Dans un premier temps, l'outil se contentera de suivre ce que le serveur IRC lui envoie. Après on pourra développer des traitements spécialisés (par exemple se souvenir des pages qui n'ont jamais été vues par les participants, etc) --NeuCeu 20 avril 2006 à 13:27 (CEST)

Proposition 2

Je propose d'implémenter cet outil collaboratif avec Ruby et FXRuby (pour l'interface) en application standalone.

Avantages

• facilité pour écrire le code
• Utilisation des threads, timeout scorch
• interface/onglets/menu/bouton (pas de chargement/changement de page)
• pas de refresh manuel (utilisation de timeout)

Inconvénients

• Mise à jour de l'application (quoique)
• installation de Ruby / Gem sur poste client.

Proposition 3

Je propose l'architecture ci-dessous, utilisant principalement Ruby on Rails pour le core, et reste suivant les besoins.

Il utilise une réplication de WP pour éviter d'attaquer le serveur sans arrêt, un core qui se charge de cette BDD, d'effectuer les tâches une et une seule fois pour tous les clients et qui sert à optimiser les traitements en servant de serveur de cache pour la BDD et en préchargeant les pages qui risque d'être demandé (historique d'une page à haut potentiel de vandalisme, contrib d'un user soupçonnable...) de manière à réduire les temps d'attente tout en gardant la charge à un niveau raisonnable.

Avantages

• Architecture n-tiers, chaque partie peut évoluer de façon interne sans trouble si l'interface de communication est bien définie
• Peut-être aisément réparti sur plusieurs machines reliées par un réseau un minimum rapide
• Prévu pour satisfaire si nécessaire tous les besoins ergonomiques/restrictions techniques
• Plus ou moins ceux des autres suivant le client choisi
• Une période d'analyse plus longue, pour bien formaliser les communications

Inconvénients

• Plus de code à écrire car plus de formalisme, plusieurs traducteurs, plusieurs clients (mais on peut rendre les utilisateurs voulant un client responsable de l'écriture du translator et client adéquate)
• Plus ou moins ceux des autres suivant le client choisi

La distinction broadcast/request est par exemple celle de l'IRC et d'AJAX: AJAX demande des infos selon les besoins du client, l'IRC prend tout par défaut et pousse les infos qu'il souhaite, par exemple en envoyant toutes les modifications, le client filtrant ce qu'il souhaite de son côté

L'architecture d'Euca33e utiliserait alors le translator IRC (avec en plus un filtrage pour ne pas envoyer les diffs, puisque récupéré par le client sur le vrai canal IRC. Dans l'idéal, les translators devraient pouvoir choisir un certain nombre d'évènements, pour lesquels il souhaitent recevoir les infos -diffs non, estimation de vandalisme, par exemple-) et non standalone (qui utilise une connexion directe), une application standalone client faisant une traduction des échanges. Avantage par rapport au translator standalone: c'est l'IRC qui prend la charge réseau. Désavantage (faible): texte, donc sans doute plus verbeux, plus de traffic global probable (mais freenode est habitue :o) ).

On peut imaginer que le request interface soit en AJAX, ce qui supprime le translator AJAX et fait passer les autres translators non-broadcats en RoR.

Proposition 4

Cette solution est basée sur IRC. L'idée c'est d'aller plus loin que le CDVF. Alors que le CDVF ne fait qu'écouter ce qui passe sur le canal IRC de browne.wikimedia.org, notre outil permettrait de se logguer complètement. Ensuite, basé sur un certain protocole basé sur des mots-clés (éventuellement assorti d'une signature GPG pour plus de sécurité), les différents clients connectés communiquent entre eux, permettant le travail collaboratif en temps réel.

Avantages

• Solution éprouvée, robuste et simple à implémenter
• Communications simples (IRC est largement documenté et des librairies externes existent)
• Chacun est libre de développer son propre client
• Possibilité d'intégration directe à la passerelle IM de Denis Dordoigne
• Pas de dépendance vis-à-vis d'une réplication de la base de données
• Pas besoin de serveur (dont nous n'avons pas le contrôle)

Inconvénients

• Développement d'un client nécessaire

RoadMap (Feuille de route)

(ceci reste une proposition)

Module 0

1. Lié à ce qui suit : structure des objets, des messages à définir
   1. Définition des objets et/ou de la BDD (tables, MCD)
   2. Nomenclature et définition des messages d'échanges (s'il y a lieu) (messages entrants/sortants, flux IRC?)
2. Internationalisation des messages à prévoir dès le début (ou tout du moins de l'interface)

Module 1

(basé sur le principe que l'appli écrit sur channel de comm et lit channel des rc et channel de comm)

1. Lecture/Écriture sur IRC (1 à X channels)
   1. Lecture sur IRC irc.wikimedia.org#fr.wikipedia
      1. Capture et parsing des événements RC
      2. Constitution d'objets : (objets à définir)
         • Liste des articles édités (états, reverté o/n...)
         • Liste des utilisateurs qui ont édités
   2. Écriture sur IRC xxx.xxxxxxxxx.xxx#xx.xxxxxx (à définir)
      1. Écriture d'information (structures des messages d'information à définir)
         1. • UserX a averti UserY au niveau Z
            • UserX propose UserY au blocage
            • UserY est bloqué
   3. Lecture sur IRC xxx.xxxxxxxxx.xxx#xx.xxxxxx
      1. Constitution d'objets :
         1. • Liste des utilisateurs avertis + niveau.
            • Liste des utilisateurs porposés au blocage
            • Liste des utilisateurs bloqués

ces trois dernières listes peuvent être gérées en une seule, avec un statut utilisateur (averti/proposé/bloqué) ...

Module 2

1. Gestion de la configuration (serveurs irc, site wikipedia, ports etc...)
2. Gestion des préférences :
   • Liste blanche/noire utilisateurs
   • Liste blanche/noire articles
   • Liste noire de mots clés

...

Module 3

1. Gestion Identification/habilitation
2. Récupération liste des utilisateurs connectés sur IRC xxx.xxxxxxxxx.xxx#xx.xxxxxx
3. Recherche heuristique
   1. Gestion des critères potentiels de vandalisme.
   2. Gestion des alertes
   3. Gestion des événements
4. Enrichissement base de connaissance sur vandalisme.
   1. Gestion des comportements
   2. Auto-enrichissement des articles les + vandalisés (whitelist dynamique?)
   3. Antécédant sur vandalisme (utilisation de la page "Historique des blocages).
5. Gestion/signalement d'une nouvelle version de l'outil (si application standalone).

...

Module 4

1. Interface
   1. Module commun : Administrateurs + Serious Fighters
      1. Interface de visualisation des RC
         1. de la liste des RC
            1. Filtrage IP/User/Newbies (Special:Contributions/newbies)
            2. Mise en valeur Validé/Averti/Blacklisté/blocké/déjà bloqué auparavant/IP d'établissement
         2. d'un diff ou diff cumulé
      2. Interface statistique (nb edits/user, nb edits/article depuis ouverture de session GTA-SF)
         1. Mise en valeur Validé/Averti/Blacklisté/blocké/déjà bloqué auparavant/IP d'établissement
      3. Interface action
         1. Action révoquer
         2. Action blanchir
         3. Action Ajouter un bandeau
         4. Action Avertir / Accueillir
         5. ....
   2. Module Administrateur
      1. Interface action
         1. Action bloquer
         2. Action protéger
         3. Action Supprimer
         4. ....

...

Autre/À définir

1. Module 3 : Gestion d'une liste des IP scolaires ou d'établissement... ???
2. Module 3 : Recherche sur copyvio ???
3. Module 3 : Correction orthographique potentielle ???
4. Module 3 : Search & replace (expression rationnelle via regexp/gsub) sur l'article ou le diff ???
5. Module 4 : Chat (autre channel irc à utiliser) ???
6. Module 4 : Affichage d'images uploadées ???
7. Module 4 : Gestionnaire de Bots en Ruby ???
8. Module 4 : Indicateur defcon (ratio nb_edit / nb_figther présents) ???

...

Prises de décision

1. plateforme de développement (serveur cvs etc???)
2. langage de développement (Ruby?)
3. architecture web / interface standalone (FXRuby?) ou web (Ruby on Rails?)
4. utilisation d'une BDD ? (hébergement, type d'utilisation...) si oui laquelle ? (MySQL, PostgreSQL, SQLite, autres....)
5. organisation
6. versionning
7. mode de communication
8. recrutement, communication externe au groupe
9. définir les rôles, désigner un coordinateur (je le dis de suite, je ne m'y présenterai pas)

...

Voila tout ceci n'est qu'une proposition, une ébauche des idées jetées en vrac et non organisé; partant du principe que nous sommes en phase de réflexion. Donc n'hésitez pas à modifier/critiquer/ajouter. (vous avez le droit de dire que c'est un grand n'importe quoi :) ) Cordialement, Educa33^e 22 avril 2006 à 23:58 (CEST)

Contraintes à prendre en compte

Techniques

• Ne pas surcharger d'appels les serveurs Wikipédia.
• Une bonne partie des SF officie depuis des écoles, sur des machines où ils ne pevent pas nécessairement installé des logiciels, et sont derrière des proxys.
• Le nombre de machines dispo est inconnu, l'espace disque et la bande bassante qui nous y serait alloué aussi.
• Si moins des 2/3 voir 3/4 des A&SF utilisent ce logiciel, ça risque d'être insuffisant, il restera trop de collisions possibles.
• Pour donner le maximum d'information, il faut répliquer la BDD de WP fr:; et pour pouvoir des RC avec, il faut que le lag ne dépasse pas la minute, au plus. Si ce n'est pas possible, il faut mieux récupérer un dump et le mettre à jour en temps réel avec l'IRC.

Social

• Les goûts de chacun mais aussi le restrictions des lieux d'exercices peut entrainer la nécessité de disposer de nombreux moyens d'accès (IRC, IM, Web...). C'est une chaude recommandation de Denis Dordoigne (développeur de la passerelle IM et du flux RSS de RC).
• Plyd avait prévu de coder un logiciel similaire pour le Google Summer of Code (qui se déroule de fin mai à août). Soit on le laisse tenter sa chance en lui préparant le terrain et on attend août, soit on essaye de lui réserver un partie qu'il puisse présenter comme "un projet" et qui pourrait légitimement s'étaler sur cette période, soit il faudra se passer de sa coopération, car il devra bosser ailleurs (ou sur un autre projet) pour gagner le salaire qu'il aurait gagné par ce biais.

  J'avais pas vu ce message. En fait je m'en veux, j'avais même pas vu la page et je croyais que c'était tombé à l'eau :// Donc en effet, j'ai proposé deux projets pour le Google Summer of Code. Un sur les catégories, un autre que j'ai appelé "RC javascript fighter", qui correspondrait à un deuxième "SpecialRecentChanges.php" de MediaWiki (implique une mise à jour de mediawiki). La réponse de l'acceptation ou non au SoC est donnée le 23 mai. Plyd /!\ 12 mai 2006 à 18:16 (CEST)

  Donc pour info, mes propositions au Google SoC ont été rejetées. ça va pas m'empêcher de venir bosser sur ce projet :) Il ya encore du monde ici ? Plyd /!\ 24 mai 2006 à 10:03 (CEST)

  Oui (enfin j'espère :) ) Eden ✍ 24 mai 2006 à 10:25 (CEST)

  Oui, oui :) --NeuCeu 24 mai 2006 à 10:37 (CEST)