Discussion Wikipédia:Patrouille RC/Projet LiveRC 2.0

    Une page de Wikipédia, l'encyclopédie libre.
    Projet (Project) Cahier des charges (Specifications) Discussion (French only) Talk page (English and other languages)

    Création de la page[modifier le code]

    Bonjour,

    Je viens de créer cette sous-page pour le projet de développement d'un LiveRC 2.0, qui en est à sa phase la plus balbutiante. Il a été abordé lors de la réunion sur la patrouille du relatée sur le BULPAT.

    N'hésitez pas à vous inscrire sur la page projet et à améliorer celle-ci.

    — Jules* Discuter 9 février 2022 à 13:31 (CET)Répondre[répondre]

    P.-S. : j'ai aussi une hypothèse, difficilement vérifiable, qui est que la baisse du nombre de patrouilleurs que je perçois depuis quelques années (demeure à vérifier si c'est une réalité ou juste ma perception) est en partie due à l'absence d'outil vraiment adapté (LiveRC ayant des problèmes d'ergonomie, une interface désormais peu moderne, etc.). — Jules* Discuter 9 février 2022 à 13:41 (CET)Répondre[répondre]

    Envisager de partir de bases existantes[modifier le code]

    Bonjour,

    Comme déjà indiqué plusieurs fois, je considère qu'aujourd'hui nous avons un outil qui rempli assez bien certaines fonctionnalités de LiveRC, sans cumuler ses défauts (une équipe de maintenance active, interface moderne et adaptée aux mobiles, très facile à utiliser) : meta:SWViewer. Cet outil est loin d'être parfait, et nécessiterait probablement encore beaucoup de corrections (interruptions régulières du flux de modifications par exemple), et a le défaut d'être uniquement ouvert aux personnes qui possèdent le rôle "révocateur" sur au moins un wiki de la WMF.

    Plutôt que de partir en terrain inconnu, ne faudrait-il pas réfléchir à partir d'un outil déjà utilisé, voir peut être même se concentrer sur développement de celui-ci⁣ ?

    Pour moi, cela aurait plusieurs avantages :

    • Un outil international, et donc un travail qui permettrait à tous les wikis d'en profiter
    • Une utilisation simple et similaire sur tous les wikis, ce qui faciliterait la patrouille sur plusieurs wikis, voir la patrouille cross-wiki
    • Moins de travail de développement de base, et donc plus de temps disponible pour travailler sur des ajouts spécifiques

    Cependant, plusieurs questions se poseraient alors :

    • Comment mettre en accord les besoins de la communauté française et de cet outil international ?
    • Est-ce que les développeurs de cet outil seraient d'accord de le confier à un développeur payé par WMFr?
    • Il faudrait aussi envisager un changement dans le statut de révocateur obligatoirement nécessaire. Sur beaucoup de wikis, le statut de révocateur est plus facile à obtenir (voir par exemple l'historique de en:Wikipedia:Requests_for_permissions/Rollback), ce qui explique le choix de cette limite pour un outil qui est quand même très puissant (possibilité d'annuler des modifications sur tous les wikis très rapidement). Il faudra peut-être envisager des évolutions du statut sur la Wikipédia francophone, mais de mémoire des évolutions proposées récemment ont été refusées par la communauté.

    Je parle de l'outil que je connais, et je pense qu'il serait aussi possible d'utiliser d'autres outils comme base, en tout cas ce serait probablement plus simple que de commencer à zéro. — RG067 (discuter) 9 février 2022 à 13:54 (CET)Répondre[répondre]

    Hello @RG067 et merci. Tu as parfaitement raison quant au fait qu'il faut l'envisager ! D'ailleurs, même si ça s'avère n'être pas possible (par exemple si plus simple de repartir de zéro, si les devs actuels ne sont pas chauds pour une intervention extérieure, etc.), regarder ce qui est bien et ce qui ne l'est pas dans les différents outils sera forcément utile.
    S'agissant de ce logiciel, je l'intègre à la liste sur la page principale. Je l'avais essayé, l'interface est effectivement moderne, l'ergonomie plutôt pas mal, mais il manque un certain nombre de fonctionnalités de LiveRC.
    Amitiés, — Jules* Discuter 10 février 2022 à 17:21 (CET)Répondre[répondre]
    Il s'agit peut-être d'un travail assez long, mais il faudrait aussi envisager de comparer chacun des outils de la liste, en essayant de tirer le bon de chaque dans le cas de la création d'un nouvel outil. Je vais me permettre de créer un tableau ici, afin de commencer calmement avant de le placer sur la page principale s'il se révèle utile. — RG067 (discuter) 10 février 2022 à 17:40 (CET)Répondre[répondre]
    Émoticône J'avais commencé à modifier la page principale pour faire la même chose. Bon, je publie quand même (c'est juste la structure) et on pourra remplir ensuite. — Jules* Discuter 10 février 2022 à 17:46 (CET)Répondre[répondre]
    Ton tableau est mieux que ce que j'ai fait, n'hésite pas à le déplacer sur la page principale. — Jules* Discuter 10 février 2022 à 17:51 (CET)Répondre[répondre]
    C'est fait, merci. Je vais essayer de commencer à le compléter, mais il faudrait le maximum d'avis pour être représentatif. — RG067 (discuter) 10 février 2022 à 17:57 (CET)Répondre[répondre]
    OK ; je complèterai demain après-midi avec mes remarques. On pourra déposer un message sur le BULPAT dans quelques jours pour demander d'autres avis. Je suggère que l'on signe (juste le pseudo, la date n'est pas utile) chaque puce que l'on ajoute, histoire de voir qui a ajouté quoi. — Jules* Discuter 10 février 2022 à 17:59 (CET)Répondre[répondre]
    J'ai fait ça, d'autres remarques me viendront surement plus tard. Pour le message sur le BULPAT. Bonne soirée Émoticône sourireRG067 (discuter) 10 février 2022 à 18:08 (CET)Répondre[répondre]
    Bonjour Émoticône. C-Helper ne permet pas la patrouille, mais il y a peut être des choses intéressantes à prendre (messages, bandeaux…). — LucienB Allo ? 11 février 2022 à 13:28 (CET)Répondre[répondre]
    Carrément. — Jules* Discuter 11 février 2022 à 13:47 (CET)Répondre[répondre]
    Totalement d'accord (d'ailleurs, chez vous aussi C-Helper s'affiche bizarrement parfois?) — RG067 (discuter) 11 février 2022 à 14:21 (CET)Répondre[répondre]
    Pas de problèmes particuliers, mais je ne l'utilise pas très souvent. — LucienB Allo ? 11 février 2022 à 17:27 (CET)Répondre[répondre]
    Je n'utilise pas C-helper, auquel je préfère RevertDiff et DiffExtension de LiveRC (pour annuler et avertir les utilisateurs) et une partie de xpatrol (pour ajouter des bandeaux sur les articles). — Jules* Discuter 12 février 2022 à 16:06 (CET)Répondre[répondre]
    Je viens d'installer DiffExtension, trop cool ! Je suis décidément loin d'avoir fait le tour de LiveRC et je souhaite bon courage au(x) développeur(s) de la prochaine version ! Il faudrait que je teste les autres outils, on verra ça lundi… Bon dimanche ! — LucienB Allo ? 12 février 2022 à 19:05 (CET)Répondre[répondre]

    Suite[modifier le code]

    Bonjour,

    Nous avons fait un premier travail exploratoire : bilan des outils existant et liste de leurs avantages et inconvénients. Merci !

    Je vais reprendre contact avec l'association Wikimédia France par courriel pour savoir comme procéder pour la suite et notamment quels seront nos interlocuteurs dans l'asso.

    Amicalement, — Jules* discuter 21 février 2022 à 14:35 (CET)Répondre[répondre]

    Je fais une petite réunion en visio avec les salariés de WMFr le prochain pour les introduire à ce projet, et ensuite les discussions passeront par ici Émoticône sourire. — Jules* discuter 4 mars 2022 à 16:22 (CET)Répondre[répondre]
    Hello ! Quelques nouvelles. Naphsica Papanicolaou WMFr, Rémy Gerbet WMFr et moi avons échangé hier. Je leur ai exposé notre besoin et notre souhait, et leur ai présenté le petit travail préparatoire que nous avions effectué (comparaison des outils existant).
    Sur le principe, l'association est d'accord pour financer le projet.
    Concrètement, voici ci-dessous les prochaines étapes (je vous laisse compléter ou corriger en réponse).
    • Construire un cahier des charges, en listant toutes les fonctionnalités que doit avoir le logiciel. Ce sera à nous de jouer, mais l'aide de bénévoles avec des compétences techniques (pour affiner) sera nécessaire, donc la liste de discussion « Wikitech » de WMFr a été mise dans la boucle.
    • Arkanosis a souligné par courriel que LiveRC étant utilisé dans quelques autres versions linguistiques (qu'il faudrait d'ailleurs que nous recensions) de Wikipédia, il ne faut pas se contenter de développer le logiciel dans notre coin et de simplement prévoir la localisation linguistique de l'interface. Il faut inviter les patrouilleurs d'autres versions linguistiques (celles utilisant LiveRC, mais aussi informer les autres) à participer à la définition du cahier des charges. Les autres communautés ont aussi des compétences techniques dont le développement du logiciel peut bénéficier.
    • Une fois le cahier des charges défini, avec l'aide précieuse des bénévoles ayant des compétences techniques, il faudra que WMFr détermine le prix/coût, pour l'intégrer à son budget (ou, s'il est élevé, demandé l'appui de la WMF ou d'autres chapitres).
    • WMFr publiera ensuite un appel d'offre.
    Amitiés, — Jules* discuter 10 mars 2022 à 10:35 (CET)Répondre[répondre]
    Re tout le monde : je propose que l'on commence le cahier des charges, avec grosso modo trois étapes :
    1. Dans un premier temps, je propose que l'on fasse ça dans une nouvelle section ci-dessous, sous forme de liste, avec un item par fonctionnalité (avec possibilité de discuter sous chaque item, pour plussoyer la fonctionnalité, la discuter, etc.).
    2. Dans un second temps, lorsque nous avons déjà bien avancé (tout en laissant courir la première étape), nous contactons les autres communautés linguistiques, notamment celles utilisant LiveRC, pour recueillir leurs besoins.
    3. Dans un troisième temps, nous faisons la synthèse des fonctionnalités dont le besoin fait consensus, nous mettons en forme la liste, nous l'ordonnons logiquement, les techniciens apportent d'éventuelles précisions techniques, etc. et nous déplaçons le cahier des charges sur la page principale.
    Des avis sur cette manière de procéder ? (notamment @Arkanosis, @Mathis B, @0x010C, @Thibaut120094 et @Gratus et toute autre personne avec des compétences techniques et/ou l'habitude de mener ce genre de projet, ce qui n'est pas mon cas)
    Jules* discuter 15 mars 2022 à 13:26 (CET)Répondre[répondre]
    @Jules* Cela me semble être une bonne base de fonctionnement. Il faudra juste penser à traduire notre ébauche avant de contacter les autres communautés Émoticône. — 0x010C ~discuter~ 21 mars 2022 à 10:32 (CET)Répondre[répondre]
    @Rémy Gerbet WMFr et @Naphsica Papanicolaou WMFr : nous avons commencé la première itération du cahier des charges ci-dessous (#Cahier des charges V1), pour info Émoticône sourire. — Jules* discuter 22 mars 2022 à 13:21 (CET)Répondre[répondre]
    J'approuve l'approche, @Jules* Émoticône sourire
    Je recommande de construire le cahier des charges de façon à rendre possible des livraisons intermédiaires (ie. commencer petit, puis ajouter progressivement des fonctionnalités au-dessus de l'existant, en permettant aux utilisateurs de tester à chaque nouvelle livraison). Ceci afin d'éviter un « effet tunnel » où le développement serait confié dans son ensemble à un prestataire sur la seule base du cahier des charges, pour se rendre compte lors de l'unique livraison au bout de 6 mois / 1 an / … que le résultat n'a rien à voir avec les attentes. Accessoirement, cela peut aussi faciliter le financement, en n'ayant à prévoir un budget que pour les N premières livraisons, avec l'obtention de financements supplémentaires pour les livraisons suivantes facilitée par la démonstration de l'utilité de ce qui a déjà été réalisé.
    Amicalement — Arkanosis 3 avril 2022 à 00:18 (CEST)Répondre[répondre]
    Merci (beaucoup) pour la recommandation, @Arkanosis ! Ce découpage semble très opportun, voire essentiel. Chronologiquement, je pense que ce découpage du cahier des charges devra intervenir après la dernière itération du recueil des besoins de la communauté. Je vais la faire figurer dans le calendrier prévisionnel. — Jules* discuter 3 avril 2022 à 10:40 (CEST)Répondre[répondre]
    +1 pour les livraisons intermédiaires. — LucienB Allo ? 4 avril 2022 à 13:01 (CEST)Répondre[répondre]

    Aide[modifier le code]

    Bonjour,

    Si je comprends bien, l'objectif de ce projet est de faire un outil « à partir de 0 » qui reprendrait les meilleurs des outils et gadgets existants.

    J'ai des compétences pro dans la conception et l'intégration de logiciels/sites, donc n'hésitez pas à me mettre dans la boucle.

    Par contre, est-ce qu'on s'oriente vers du JS (avec les chargements et limitations qui vont avec) ou un programme .exe qui permet de s'amuser niveaux graphismes et traitements avec « juste » des appels API via OAuth?

    Gratus (discuter) 9 mars 2022 à 23:48 (CET)Répondre[répondre]

    Notification Gratus : Bonjour,
    Une discussion a justement été lancée cette après-midi sur la liste du groupe technique de Wikimédia France dont Notification Jules* est en copie, je pense qu'on pourrait t'y ajouter sans problème, ping Notification Rémy Gerbet WMFr.
    À priori on part pour conserver l'intégration en gadget, donc du JS.
    Cordialement, --Mathis B discuter, le 9 mars 2022 à 23:59 (CET)Répondre[répondre]
    Nice! — Gratus (discuter) 10 mars 2022 à 03:26 (CET)Répondre[répondre]
    Notification Gratus : Hello, Oui pas de soucis pour t'ajouter à la liste tech :) Il me faudrait seulement une adresse mail. Rémy Gerbet WMFr (discuter) 10 mars 2022 à 09:30 (CET)Répondre[répondre]

    Cahier des charges V1[modifier le code]

    Bonjour @Hyméros, @RG067, @LucienB49, @Jean-Mahmood, @Mathis B, @Culex, @Golmote, @Martin-78, @LD et @Ryse93, @Thibaut120094, @Qwerty1999, @Od1n, @Juste Juju et @Loïs WAHL.

    @0x010C et moi avons pris quelques heures en vocal pour établir une base de cahier des charges. Pour cela, nous avons utilisé le tableau comparatif des outils, la liste des suggestions pour Cuddle (2015), et nous avons étudié plus en détail LiveRC et SWViewer.

    Chaque point est évidemment ouvert à la discussion (dans la section dédiée, histoire que ça reste lisible), de même que l'ajout d'autres éléments. Le but étant de parvenir à quelque chose de consensuel, avec les fonctionnalités communément considérées comme utiles et pertinentes, tout en visant (cf. les objectifs) un outil à l'interface beaucoup plus aérée et simple que celle de LiveRC (donc plutôt dans l'esprit de l'interface de SWViewer, mais avec la richesse de LiveRC).

    Pour la méthode, je propose que l'on fonctionne par itérations : ceci est la première itération du cahier des charges, on en discute puis on fait une autre itération incorporant tous les ajouts/supp./modifs consensuels qui ont émergé pendant les discussions ; ensuite la même chose avec les retours des patrouilleurs des autres wiki ; etc.

    Il y a aussi des questions posées (#Questions) : n'hésitez pas à y répondre directement en signant votre message.

    À vous ! ÉmoticôneJules* discuter 22 mars 2022 à 13:01 (CET)Répondre[répondre]

    Description du projet[modifier le code]

    Contexte[modifier le code]

    L'outil LiveRC, traditionnellement utilisé sur Wikipédia en français pour la patrouille, n'est quasiment plus mis à jour depuis 2014 environ. Quelques autres contributeurs (merci à eux) le maintiennent un peu de temps à autre pour que l'outil continue de tourner, mais il ne fait plus l'objet d'aucun développement, d'aucune amélioration. Son code est en outre obsolète : par exemple, il y a de nos jours des moyens plus efficaces pour récupérer la liste des modifications récentes, en temps réel. Enfin, LiveRC a une interface qui manque d'ergonomie (interface très chargée, liens très petits avec risques de missclik, etc.), arbore un look aujourd'hui désuet, manque de certaines fonctionnalités et en compte d'autres peu utilisées.

    Objectifs[modifier le code]

    Les objectifs sont :

    • un logiciel qui soit adapté aux usages de la patrouille de Wikipédia francophone et, autant que possible, des patrouilleurs d'autres wikis (notamment ceux utilisant déjà LiveRC) ;
    • un logiciel qui conserve toutes les fonctionalités ''utiles'' de LiveRC et intègre des fonctionnalités manquantes (certaines inspirées de SWViewer, d'autres demandées par les patrouilleurs) ;
    • un logiciel qui soit relativement facile à prendre en main : il faut donc délaisser un certain nombre d'options inutiles et parfois saugrenues présentes dans LiveRC et surtout simplifier, épurer l'interface ;
    • un logiciel qui soit robuste techniquement, utilise les dernières fonctionnalités permises par Mediawiki, puisse être facilement maintenu (code bien structuré, documenté, etc.).

    Périmètre[modifier le code]

    Cet outil sera à destination des utilisateurs avec déjà une petite expérience des wikis Wikimedia (pas les débutants, mais le logiciel ne doit pas être accessible qu'aux utilisateurs les plus expérimentés). [question non résolu : Dans quel contexte l'outil sera utilisé ? dans quel environnement ?]

    Environnement technique[modifier le code]

    Application web, essentiellement codé en JavaScript. Utilisation importante de l'API MediaWiki. Utilisation d'EventStream pour la récupération des modifications en temps réel Deux options :

    • sous forme de gadget MediaWiki
    • outil externe hébergé sur WikiMedia Cloud Services (authentification via OAuth)

    Fonctionnalités / besoins[modifier le code]

    Note : lorsqu'il est indiqué diff, il peut alternativement s'agir d'une entrée de journal.

    • Une liste des modifications récentes
      • actualisée en temps réel
      • possibilité de mettre en pause (suspend l'affichage des nouveaux diffs)
      • une ligne représente un diff ou une entrée de journal (il faut avoir une surface de clic agréable)
      • un clic n'importe où sur la ligne ouvre l'aperçu du diff
      • des raccourcis clavier permettent de naviguer entre les diffs de la liste
      • après avoir cliqué sur une ligne de diff, au choix (en option) :
        • la ligne disparaît de la liste ;
        • la ligne demeure mais est marquée comme lue au moyen d'un élément visuel.
      • un bouton « précédent » permet de réafficher les précédents diffs visualisés
      • un bouton pour vider la liste
      • une ligne contient les éléments suivants (sous forme textuelle ou signifié par un élément visuel) :
        • heure
        • l'auteur de la modification/entrée
          • nom utilisateur / IP
          • statut
          • blocage actuel ou antérieur (éventuellement nombre)
          • nombre de contributions
          • nombre de fois où l'utilisateur a été révoqué dans la session
        • le titre de la page correspondante
        • statuts de protection de la page
        • résumé de modification (éventuellement tronqué)
        • différence en octet
        • certaines balises pertinentes (prédéfinies : par ex. reverts, blanchiments, etc.) (attention, certaines balises sont propres à chaque wiki, via AbuseFilter)
        • score ORES
      • critères de filtrage
        • nombre de contributions de l'utilisateur
        • ancienneté de l'utilisateur en nombre de jours
        • statuts (IP, utilisateur enregistré, autoconfirmed, autopatrolled, admin, bot)
        • espaces de nom
        • types de journaux (nouvelles pages, suppressions, protections, renommages, etc. + modifications bloquées par les filtres anti-abus)
        • score ORES
        • un système de whitelist/blacklist pour :
          • utilisateurs
          • balises
        • options permettant d'outrepasser les critères ci-dessus pour :
          • mes propres modifications
          • les révocations
          • les blanchiments
          • pages de la liste de suivi
    • Un composant d'aperçu des diffs
      • affichage classique du diff
      • naviguer entre les diffs d'une même page via des raccourcis clavier
      • Vis à vis de l'auteur de la modification
        • Informations :
          • nom d'utilisateur/IP → lien = liste des contributions
          • lien vers sa pdd (lien rouge si pdd n'existe pas)
          • statut
          • lien Whois
          • lien IPQualityScore (ou service similaire de détection de proxies ouverts)
        • Actions réalisable :
          • [admins] bloquer (éventuellement dépose d'un message de notification de blocage inclu sur la pdd) / [???] requête de blocage
          • [???] laisser un message (dépose un modèle)
          • cacher l'utilisateur : ses modifications n'apparaissent plus dans la liste des modifications récentes
      • Vis à vis de la page
        • Informations :
          • titre de la page (inclu le namespace) → lien = page
          • lien historique
          • lien discussion
          • lien modifier
          • lien protéger
        • Actions réalisables :
          • [admins] supprimer / [???] requête de suppression
          • [???] ajouter un bandeau, uniquement pour les nouvelles pages
          • [admins] protéger / [???] demander une protection
          • Recherche de copyvio avec Earwig's Copyvio Detector (exemple)
      • Vis à vis du diff :
        • Informations :
          • horodatage ancienne et nouvelle version
          • résumé de modification complet
          • liste exhaustive des balises
        • Actions réalisables :
          • [???] annuler
          • [???] révoquer [accessible pour tous où avec le status révocateur uniquement ?]
          • [admin] masquer / [???] requête de masquage
          • relire la modification|
          • afficher les images au survol
          • sélection d'un texte puis clic droit > rechercher sur le web
          • naviguer vers la modification précédente (et les précédentes, successivement, jusqu'à trouver une version saine) et pouvoir appliquer les mêmes actions que pour le diff le plus récent
      • pour toutes les actions
        • choix du motif dans une liste déroulante importée de WP (pour les actions admin) ou personnalisable dans le logiciel (pour les autres)
        • pouvoir préciser un motif manuellement
        • actions combinable avec une dépose de message sur la pdd de l'utilisateur en un clic.
        • actions réalisables via des raccourcis clavier
    • Composant barre d'état
      • Bouton donnant accès à la liste des diffs que l'on a visualisés pendant la session.
      • Statistiques :
        • sur le nombre de reverts via le logiciel dans les x dernières minutes
        • sur le nombre de patrouilleurs utilisant le logiciel dans les x dernières minutes
      • Notifications visuelles (comme dans l'interface de Wikipédia) lorsque le patrouilleur :
        • reçoit un message sur sa pdd,
        • reçoit une notification ou un remerciement.

    Questions[modifier le code]

    • sur les usages actuels de LiveRC :
    • autres :
      • pour les patrouilleurs cross-wiki, est-ce que LiveRC 2.0 aurait une plus-value par rapport à SWViewer ? (Donc est-ce que l'on intègre la possibilité d'afficher les modifs récentes de plusieurs wikis dans LiveRC 2.0 ?)
        • Si les fonctionnalités ici décrites sont développées, oui. Plusieurs points d'attention si l'on veut s'en servir comme service cross-wiki : il faut que les équivalents des modèles (avertissement, SI...) pour chaque wiki soit mis en place, pour pouvoir avertir/demander une suppression avec les modèles locaux du wiki ; il faudra aussi limiter la fonctionnalité d'utiliser plusieurs wikis en simultané à un certain statut (actuellement, il faut le rollback sur au moins un wiki pour accéder à SWViewer. Mais concentrons-nous d'abord sur un outil pour des communautés locales je pense, SWViewer étant suffisant pour faire des la patrouille cross-wiki (cela demande moins de fonctionnalités, par exemple je ne marquerais pas des modifications comme relues sur SWViewer même si cela était possible). — RG067 (discuter) 22 mars 2022 à 18:51 (CET)Répondre[répondre]
        • Je pense que ne pas prévoir dès de début la possibilité de gérer le multi-wiki (même sans l'implémenter dans un premier temps) serait une erreur, ne serait-ce qu'avec l'importance qui ne peut être amenée qu'à grandir des interactions avec Commons / Wikidata / Wikifunctions — Arkanosis 2 avril 2022 à 23:07 (CEST)Répondre[répondre]
      • Quel est le public ciblé ? Même si tous les utilisateurs pourront "voir", faut-il par exemple le statut de rollbacker pour pouvoir utiliser les fonctionnalités avancés ? (cf les [???] dans la section Fonctionnalités)
      • deux options de développement (incompatibles) s'offrent : A. soit envisager un support mobile, mais plusieurs questions se posent : y a-t-il un besoin ? est-il souhaitable de patrouiller sur mobile (risques de maladresses, quid des questions de nouveaux auxquelles il faut répondre, etc.) ? le logiciel SWViewer n'y suffit-il pas ? B. soit envisager un mode modulaire et supportant le multifenêtre (voir http://golden-layout.com/) qui permet aux patrouilleurs d'agencer leur espace de patrouille comme ils le souhaitent.
        • Plutôt favorable à l'option B, utile. Un support mobile ne serait pas inutile, mais il y a déjà SWViewer et Huggle qui sont facilement utilisables sous mobile, et j'admets avoir des réserves quant à l'opportunité de patrouiller sous mobile : la patrouille, ce n'est pas que des reverts, mais aussi des avertissements personnalisés, des retouches d'orthographe ou de typo sur les articles, des explications aux nouveaux, etc., autant de choses qui sont plus compliquées, sous mobile, que juste cliquer sur « révoquer ». — Jules* discuter 23 mars 2022 à 19:57 (CET)Répondre[répondre]
        • D'accord avec Jules et ses réserves d'une utilisation sur mobile. — LucienB Allo ? 24 mars 2022 à 13:22 (CET)Répondre[répondre]
        • pour l'options B. pratique d'avoir des fenêtres détachées pour pouvoir les placer où nous voulons. Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:11 (CET)Répondre[répondre]
        Est-ce que les deux options sont réellement incompatibles ? Même s'il est vrai que la patrouille, ce n'est pas que des reverts, je trouve dommage de se priver de la possibilité de faire aussi des reverts sur une interface simplifiée lorsqu'on est loin de son PC.
        (Et aussi, je précise, que Huggle n'existe pas sur mobile.) ίᖆᘺᙅ @#! 24 mars 2022 à 13:47 (CET)Répondre[répondre]
        Techniquement non, mais ça nécessiterait le développement de deux interfaces totalement différentes, induisant temps et coûts supplémentaires. Concrètement, il faut faire des choix. — Jules* discuter 27 mars 2022 à 13:21 (CEST)Répondre[répondre]
        • Favorable à l'option B, je ne suis pas sûr que patrouiller sur un mobile soit pertinent, personnellement je ne le ferai pas et je préfèrerai avoir une intervalle modulaire. --Martin-78 (discutailler) 2 avril 2022 à 22:11 (CEST)Répondre[répondre]
        • La patrouille sur mobile est indispensable selon moi (sans surprise)… mais je ne suis pas certain que ce soit à LiveRC de répondre à ce besoin, les bonnes interfaces utilisateur sur ordinateur et sur mobile ne partageant pas beaucoup de caractéristiques. Plutôt favorable à l'option B, donc : un LiveRC très bon à une chose plutôt que médiocre à deux choses — Arkanosis 2 avril 2022 à 23:07 (CEST)Répondre[répondre]
        • B sans hésitation. --Hyméros --}-≽ 4 avril 2022 à 18:46 (CEST)Répondre[répondre]
        • B et Contre fort la patrouille RC sur téléphone mobile qui a mon sens serait totalement ingérable ! — Juju [💬 Discuter], le 9 avril 2022 à 22:18 (CEST)Répondre[répondre]

    Discussions[modifier le code]

    • Dans la mesure du possible, s'orienter vers une page légère. Personnellement, je n'utilise pas LiveRC parce qu'il faut plusieurs secondes à la page pour se charger. Lorsque je change d'onglet pendant quelques minutes et que je reviens à nouveau sur LiveRC, il n'est pas rare que la page se recharge à nouveau complètement. Bref, il me semble que le tout javascript actuel fait inutilement gonfler les besoins en RAM et que cela cause quelques frustrations qui doivent en détourner plus d'un. Une gestion des pages plus classique, l'imh coté serveur avec du javascript pour les mises à jour en temps réel, me semble plus indiquée pour s'adresser au plus grand nombre. ίᖆᘺᙅ @#! 22 mars 2022 à 15:45 (CET) (J'utilise Huggle)Répondre[répondre]
    • Version mobile. Je ne peux pas me prononcer sur l'utilité de SWViewer, je n'ai pas les droits pour l'utiliser, et c'est pour cela que je confirme le besoin d'une version mobile. C'est ce que je me dis à chaque fois que je parcours les "modifications récentes" depuis mon téléphone: Le plus important est qu'il faut limiter le nombre de clics (par exemple pour voir le contenu d'un diff) au minimum. Idéalement, zéro. Une simple page en scroll qui récapitule chronologiquement les derniers diff avec au moins le bouton "annuler" permettrait de se débarrasser rapidement des vandalismes manifestes. ίᖆᘺᙅ @#! 22 mars 2022 à 15:45 (CET)Répondre[répondre]
    • Filtre web mobile : dans les filtres de l'outil, j'aimerai qu'il y ait un filtre basé sur le type de connexion web de l'auteur de la modif (web desktop/web mobile).--Bertold Brecht >dissoudre le peuple< 22 mars 2022 à 18:48 (CET)Répondre[répondre]
      Hello @Gpesenti. Bien d'accord que c'est utile. Pour info c'est déjà inclus dans le cahier des charges ci-dessus, mention « balises » dans système de whitelist/blacklist : en effet le type de connexion web de l'auteur de la modif est indiqué par Mediawiki sous forme de balise. Bien à toi, — Jules* discuter 22 mars 2022 à 18:58 (CET)Répondre[répondre]
      ok. c'était pas explicite pour moi Bertold Brecht >dissoudre le peuple< 22 mars 2022 à 18:59 (CET)Répondre[répondre]
    • PDD du compte/IP : dans la mesure du possible, mettre en place un système qui affiche si l'IP/le compte a reçu récemment des modèles Test, des avertissements de suppression immédiate ou des avertissements pour copyvio sur sa pdd. — RG067 (discuter) 22 mars 2022 à 18:53 (CET)Répondre[répondre]
      +1, permet un meilleur suivi. Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)Répondre[répondre]
      +1, important pour le suivi. — LucienB Allo ? 24 mars 2022 à 13:41 (CET)Répondre[répondre]
      +1, très pratique pour le suivi Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:23 (CET)Répondre[répondre]
      +1 --Hyméros --}-≽ 4 avril 2022 à 18:51 (CEST)Répondre[répondre]
    • Requêtes : Pour les requêtes qui nécessitent un bandeau + une demande sur la page concernée (je n'ai que SI en tête, je ne sais pas s'il y en a d'autre), faire en sorte que les 2 actions soient réalisées. Actuellement, je crois que LRC ne mets que le message sur la page de requête. — RG067 (discuter) 22 mars 2022 à 18:55 (CET)Répondre[répondre]
      +1, bien vu ! — Jules* discuter 22 mars 2022 à 19:02 (CET)Répondre[répondre]
      +1 Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)Répondre[répondre]
      +1 — LucienB Allo ? 24 mars 2022 à 13:41 (CET)Répondre[répondre]
      +1 --Hyméros --}-≽ 4 avril 2022 à 18:51 (CEST)Répondre[répondre]
    • Design de l'interface

    Ne sachant plus pourquoi je n'utilise pas LiveRC, je l'ai "chargé" ce soir. J'avais du le charger une fois il y a 4-5 ans et puis je ne l'ai jamais plus utilisé, mais je n'arrivais pas à me souvenir pourquoi cet outil me rebutait. Son interface est trop chargée avec un tas d'informations inutiles. L'interface n'est pas intuitive et il faut manifestement une mini-formation pour débuter. Précision utile, j'utilise efficacement dans mon métier de multiples outils de filtrage de données. --Bertold Brecht >dissoudre le peuple< 23 mars 2022 à 19:51 (CET)Répondre[répondre]

    Tout à fait d'accord. C'est d'ailleurs le premier problème de LiveRC à mon sens. — Jules* discuter 23 mars 2022 à 19:54 (CET)Répondre[répondre]
    À mon sens aussi, le principal problème de LRC. Il faudra bien insister là-dessus auprès de l'équipe/de la personne chargée de réaliser le projet. — RG067 (discuter) 23 mars 2022 à 20:05 (CET)Répondre[répondre]
    Pour moi aussi. Une interface trop chargée peu déstabiliser des débutant qui voudrait lutter contre le vandalisme. Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:25 (CET)Répondre[répondre]
    • Multi-wiki

    Ce serait une bonne chose d'avoir la possibilité de cocher les wikis pour lesquels on souhaite recevoir les modifications en temps réel (Sur le modèle de ce que propose Huggle), pour avoir par exemple les wiki fr et commons dans un même flux.

    • Responsabilité concernant l'usage de l'outil

    Il est écrit plus haut que l'outil doit être facile à utiliser, mais qu'il est à « destination des utilisateurs avec déjà une petite expérience des wikis Wikimedia ». La facilité est un point important afin d'avoir une patrouille efficace, à condition que cette activité soit faite par des personnes raisonnables. Vous vous souvenez des expériences passées où des utilisateurs mettent LiveRC en route avec moins de 50 contributions à leur compteur... L'accès à LiveRC doit donc être limité à des personnes qui en font la demande (après avoir patrouillé « à la main »), exactement comme l'est l'outil de révocation ; pour moi les deux sont au même niveau de « puissance » et doivent donc être traités comme tel. Trizek bla 24 mars 2022 à 13:51 (CET)Répondre[répondre]

    @Trizek De mon expérience personnelle, je n'aurais jamais effectué la moindre patrouille si LiveRC avait nécessité un statut de révocateur ou une demande d'accès explicite. C'est parce qu'il était accessible à tous que j'ai pu le découvrir, et que j'ai découvert dans le même temps le concept de la patrouille.
    De toute façon, l'outil ne donne pas plus de droits que ce qui est déjà faisable via l'interface de Wikipédia. Il requiert juste quelques clics en moins. --Golmote (discuter) 24 mars 2022 à 20:06 (CET)Répondre[répondre]
    Je suis également assez défavorable pour conditionner l'usage de l'outil à une autorisation explicite, ça va contre l'exprit du « n'hésitez pas » wikipédien. Au pire, rien n'empêche de « brider » Live RC 2.0 en limitant à X actions par minute pour les « nouveaux » si vraiment on a peur d'abus.— Gratus (discuter) 25 mars 2022 à 17:30 (CET)Répondre[répondre]
    Idem : le statut autopatrolled me semble suffisant (+ possibilité pour chaque communauté de paramétrer ça). Et ça évite de fait que des comptes avec 50 modifs l'utilisent, @Trizek. — Jules* discuter 25 mars 2022 à 20:04 (CET)Répondre[répondre]
    @Golmote, la patrouille est effectivement déjà accessible pour n'importe qui avec les outils standards. C'est par ce biais que j'en ai fait pendant quelques années. Les quelques clics en moins permis par LiveRC sont pour certaines personnes une invitation à aller plus vite, et donc, hélas, à faire moins bien.
    Pour la plupart des statuts ouvrant à des outils puissants (révocation, qui est un clic en moins ; blocage...), il est demandé de démontrer que l'on en a le besoin. LiveRC étant un outil puissant, je répète qu'il me semble important d'avoir démontré un besoin pour l'utiliser, mais aussi (surtout !) d'avoir déjà démontré que l'on sait patrouiller efficacement et en suivant les règles et bonnes pratiques de la patrouille. Avec un simple accès par le fait d'atteindre un seuil de temps et de contributions, ce contrôle n'existe pas ; cela peut mener à des abus qui ont déjà été dommageables pour des nouveaux, et déplaisants à entendre pour la patrouille.
    @Gratus @Jules*, le statut d'autopatrolled est un bon début. Pour réellement démontrer que la patrouille est quelque chose de sérieux effectué en responsabilité par des gens raisonnables, j'irai un cran plus loin. :)
    Trizek bla 26 mars 2022 à 11:35 (CET)Répondre[répondre]
    Je comprends mais je ne suis pas d'accord : ce serait une barrière trop élevée à l'entrée (et de la bureaucratie en plus). Il y a déjà eu des abus avec LiveRC, mais pas suffisamment fréquents pour ériger une telle barrière à mon sens (sans compter qu'on manque de patrouilleurs — sérieux — ces temps-ci).
    Ça n'empêche pas de veiller dans la manière dont on construit le logiciel à ce qu'il n'encourage pas des comportements déraisonnables, et même à l'inverse qu'il facilite la communication avec les nouveaux, etc. D'où par exemple mes remarques sur la version mobile, ou encore la proposition d'avoir accès depuis le logiciel aux notifications et surtout à la notif de nouveaux messages (de sorte que le patrouilleur qui est contacté par un nouveau en soit informé rapidement), ce qui n'était pas le cas dans LiveRC. Et sans doute d'autres trucs auxquels je ne pense pas.
    On peut aussi mettre en exergue les commandements du bon patrouilleur sur la page WP d'accès au logiciel. Il faudrait peut-être actualiser ces commandements d'ailleurs ; le point 5 est discutable par exemple : nous sommes plusieurs à bloquer directement les auteurs de certains vandalismes très bêtes (je préfère consacrer du temps aux auteurs de maladresses qu'aux vandales peu susceptibles de contribuer utilement dans l'immédiat). — Jules* discuter 26 mars 2022 à 12:14 (CET)Répondre[répondre]
    • Option "buffer" sur pause

    Une possibilité de mettre en zone tampon les contributions qui continuent à arriver en mode pause me semble intéressante, ce qui n'est pas le cas avec LiveRC. — LucienB Allo ? 24 mars 2022 à 17:31 (CET)Répondre[répondre]

    Hello @LucienB49. L’intérêt/l’usage m’échappe pour être honnête : l’intérêt de la pause est, à mes yeux, de pouvoir suspendre l’arrivée des diffs quand on part faire autre chose, afin que lorsque l’on revient, on ne soit pas noyé sous les diffs publiés entretemps. Pourquoi mettre sur pause s’il y a un buffer : autant laisser les diffs s’afficher en temps réel, le résultat sera le même, non ? — Jules** bla 24 mars 2022 à 17:42 (CET)Répondre[répondre]
    Bonjour Jules** Émoticône. Lorsque les diffs arrivent en nombre sur LiveRC, il devient difficile, voire impossible de les traiter, le défilement de page étant problématique, d'où une pause. Du coup à la reprise, on a perdu le différentiel, ce que je trouve un peu dommage. — LucienB Allo ? 24 mars 2022 à 17:50 (CET)Répondre[répondre]
    Sur Huggle (encore lui), on a un buffer à la taille configurable. Quand il est plein, il arrête d'empliler les lignes, ou il remplace la ligne la plus ancienne par une nouvelle, au choix. C'est quelque chose qui devrait être prévu indépendamment du fait de pouvoir mettre en pause le défilement, ne serait-ce que parce que ça permet d'éviter une augmentation incontrolée de la mémoire utilisée. ίᖆᘺᙅ @#! 24 mars 2022 à 18:40 (CET)Répondre[répondre]
    Ok, @LucienB49 et Irwc, je comprends mieux : l’enjeu est d’arrêter le défilement pour pouvoir cibler plus aisément les diffs.
    L’option que vous proposez est intéressante, mais je note qu’il existe une alternative, qu’utilise SWViewer, à savoir l’absence de défilement automatique une fois que l’écran est rempli de lignes de diffs : au patrouilleur de scroller vers le haut (ou de traiter les diffs affichés à l’écran) s’il veut afficher les diffs plus récents, ce qui dans l’intervalle évite que les lignes de diffs ne défilent. Je vous invite à tester SWViewer sur cet aspect (sachant qu’il a un défaut : la barre de défilement est peu visible et pratique).
    Cette alternative, si bien implémentée, peut avoir l’avantage de ne pas nécessiter de la part du patrouilleur qu’il mette en pause, enlève la pause, etc. — Jules** bla 25 mars 2022 à 09:49 (CET)Répondre[répondre]
    Chez moi, Jules**, SWViewer continue à défiler malgré le remplissage des diffs ; pas de scroll possible vers le haut. Il y a peut-être une option à cocher quelque part, mais je ne connais pas bien cet outil… En tout cas, l'idée est intéressante. À quoi sert le carré de couleur avec le nombre à l'intérieur devant frwiki ? — LucienB Allo ? 25 mars 2022 à 13:30 (CET)Répondre[répondre]
    @LucienB49 C'est le score ORES, pour le carré !
    Sinon, j'ai commenté de tête sans avoir l'outil sous les yeux (je n'étais pas chez moi), et du coup j'ai dit n'imp', désolé >< !
    N'empêche que c'est faisable : on peut imaginer une mise en pause du défilement dès qu'on scrolle un peu vers le bas (autrement dit dès qu'on est plus tout en haut de la liste), ce qui éviterait d'avoir à cliquer à répétition sur un bouton « pause » ; pour info, c'est ce qui se fait sur les tchats Twitch notamment. — Jules* discuter 25 mars 2022 à 13:41 (CET)Répondre[répondre]
    Jules**, j'ai trouvé l'option "Terminer le flux", mais ça ne change rien… Oui, l'idée est vraiment à retenir — LucienB Allo ? 25 mars 2022 à 13:53 (CET)Répondre[répondre]
    • Affichage des diffs non chronologique

    Sur Huggle, un raccourci clavier (très très pratiques, les raccourcis claviers, soit dit en passant) affiche le diff suivant mais ce n'est pas un ordre chronologique. J'ai l'impression qu'il se base sur le score Ores pour afficher les plus à risque en priorité. Également, quand j'annule un diff ce sont les diffs récents du même utilisateur qui s'affichent ensuite. ίᖆᘺᙅ @#! 24 mars 2022 à 18:38 (CET)Répondre[répondre]

    • Option Recherche

    Pour moi une barre de recherche pour rechercher soit une modification déjà dans la liste ou rechercher les modifications d'un utilisateur ou d'une IP ou (encore) juste un utilisateur serait la bienvenue. soit des options à configurer dans la barre de recherche soit un clic droit sur une modif avec un menu rechercher modifications, utilisateur. Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:33 (CET)Répondre[répondre]

    • Bouton pour les 'Autopatroled'.

    un bouton pour les autopatroled qui renvoit directement sur la page Wikip%C3%A9dia:Vandalisme_en_cours. je prenait du temps à la trouver à mes début avant d'avoir l'idée de l'ajouter en favoris. mais il m'arrive de patrouiller sur un autre ordi que le mien et la je doit passer par plein de pages avant de pouvoir signaler un utilisateur. — Le message qui précède, non signé, a été déposé par Loïs WAHL (discuter)

    Hello @Loïs WAHL : pour le coup, il y aura déjà moyen de déposer automatiquement une demande de blocage sur WP:VC, donc un bouton menant à la page me semble superflu Émoticône (et on part du principe qu'une personne utilisant un logiciel de patrouille doit déjà connaître ce type de pages). — Jules* discuter 25 mars 2022 à 15:46 (CET)Répondre[répondre]
    ok @Jules*Loïs Wahl(laisse moi un message) 25 mars 2022 à 16:03 (CET)Répondre[répondre]
    • Équivalent de DiffExtension

    Je ne crois pas avoir vu ce gadget dans le cahier des charges. Très pratique en dehors de la patrouille (LS…) pour retrouver ses marques avec les outils ad hoc. Pourrait reprendre les + des autres gadgets. Vu la taille du code actuel, ça ne devrait pas être compliqué à mettre en oeuvre en le prévoyant au début du projet, sans les bugs… — LucienB Allo ? 25 mars 2022 à 17:45 (CET)Répondre[répondre]

    Sur le principe, +1. En pratique, je ne sais pas dans quelle mesure ça doit être rattaché à ce projet, vu que c'est une extension. La question se pose aussi sur le plan technique : si LiveRC 2.0 n'est pas développé comme un gadget Mediawiki, mais comme une appli web hébergée sur WMCS, j'imagine que l'extention peut demander un peu plus de développement. À voir. — Jules* discuter 25 mars 2022 à 19:54 (CET)Répondre[répondre]
    • Bouton LdS

    Un bouton pour ajouter des articles en suivi (temporairement ou non), pour suivre les articles "brûlant". Qwerty1999 (discuter) 31 mars 2022 à 23:27 (CEST)Répondre[répondre]

    Logique. — Jules* discuter 2 avril 2022 à 14:40 (CEST)Répondre[répondre]
    • Commentaire dans les bandeaux

    Permettre l'ajout de commentaires dans les bandeaux (ex. bandeau admissibilité à vérifier). Qwerty1999 (discuter) 31 mars 2022 à 23:27 (CEST)Répondre[répondre]

    Oui, ça semble indispensable ; à voir quels bandeaux sont concernés (je ne connais que celui {{admissibilité à vérifier}} qui demande un commentaire personnalisé). — Jules* discuter 2 avril 2022 à 14:41 (CEST)Répondre[répondre]
    J'ai cherché, il y en a plusieurs autres mais seul copie à vérifier pourrait être utile à l’outil. Qwerty1999 (discuter) 7 avril 2022 à 16:39 (CEST)Répondre[répondre]

    Retour d’Aymeric50800[modifier le code]

    Copié depuis le BULPAT, réponse à une relance de Jules* pour des retours sur le cahier des charges.

    Miaou Jules* Émoticône !

    Je n'utilise aucun outil externe pour patrouiller, donc je ne peux pas vraiment répondre aux questions concernant mon usage actuel de LiveRC ni me prononcer sur des pistes d'amélioration.

    J'ai lu les discussions et propositions, et voici ce que j'en pense :

    • D'accord avec les fonctionnalités proposées, rien de spécial à ajouter.
    • Pour le statut des requis ([???] des fonctionnalités), il faudrait au moins autopatrolled à mon sens, autoconfirmed étant trop simple à obtenir et présentant trop de risques d'abus. La fonction révoquer ne devrait être accessible qu'aux révocateurs.
    • D'accord pour l'option de développement B, un support mobile serait superflu.
    • D'accord avec les propositions faites en discussion suivantes :
      • Dans la mesure du possible, s'orienter vers une page légère ;
      • PdD du compte/IP ;
      • Requêtes ;
      • Design de l'interface ;
      • Bouton LdS ;
      • Commentaire dans les bandeaux.
    • Plutôt en faveur d'un hébergement sous forme de gadget.

    Voilà, bon week-end !

    Aymeric50800 2 avril 2022 à 19:12 (CEST)Répondre[répondre]

    Merci pour ce retour, @Aymeric50800 ! N'hésite pas à le copier dans Discussion Wikipédia:Patrouille RC/Projet LiveRC 2.0#Discussions (en un seul bloc, ne t'embête pas Émoticône). S'agissant de l'hébergement sous forme de gadget, pourquoi le préfères-tu ? — Jules* discuter 2 avril 2022 à 20:19 (CEST)Répondre[répondre]
    D’accord, je vais faire ça, et t’invite du coup à répondre là-bas Émoticône sourire.
    Pour l’hébergement, c’est la simplicité d’utilisation et « d’acquisition » d’un gadget qui me fait pencher plutôt pour cette option, même si j’entends les arguments développés en discussion, notamment en matière de sécurité et d’optimisation. En tant que personne ne maîtrisant pas vraiment ce sujet, peu m’importe, tant qu’en définitive le logiciel est facile d’accès aux patrouilleurs et sécurisé.
    Bien à toi,
    Aymeric50800 2 avril 2022 à 20:32 (CEST)Répondre[répondre]

    Environnement technique[modifier le code]

    Deux types sont proposés:

    • sous forme de gadget MediaWiki
      • (+) Les usagers sont en « terrain connus » avec le système de gadget.
      • (+) Le logiciel peut être modifié directement sur Wikipédia.
      • (-) La « charge de travail » est entièrement dépendante du navigateur du visiteur et de son support du JS.
      • (-) Possibilité pour l'utilisateur de modifier le code (par exemple pour outrepasser les sécurités implémentées dans le gadget).
    • outil externe hébergé sur WikiMedia Cloud Services
      • (-) On sort de Wikipédia, il faut donc « trouver » l'outil.
      • (+) Non lié à un wiki, l'outil pourrait requêter plusieurs wikis à la fois.
      • (+) On peut faire du travail côté serveur, ce qui permettra très probablement de réduire tout ce qui est temps de démarrage/mémoire utilisée.
      • (+) Avec OAuth, on peut limiter les permissions, ce qui peut « mettre en confiance » des utilisateurs avec des droits (admins, OS, CU...) mais qui ne souhaitent pas les utiliser avec Live RC 2.0.
      • (+) Code non modifiable par l'utilisateur, sécurité renforcée.
      • (-) Moins facile de modifier le logiciel.

    N'hésitez pas à modifier si vous voyez d'autres avantages ou inconvénients et indiquer laquelle vous semble préférable.— Gratus (discuter) 23 mars 2022 à 23:51 (CET)Répondre[répondre]

    Comme je le dis en discussion, l'outil hébergé me semble plus indiqué. ίᖆᘺᙅ @#! 24 mars 2022 à 00:50 (CET)Répondre[répondre]
    J'ai personnellement quelques désacords sur les points en faveur du WMCS évoqués ci-dessus :
    • sous forme de gadget on peut aussi requêter plusieurs wikis à la fois
    • qu'importe l'option retenu, si on veut un outil interactif il y aura besoin de l'exacte même quantité de JS, c'est a dire la même charge pour le navigateur du client. Dans l'hypothèse WMCS, je ne vois pas bien ce que pourrais faire le backend au delà de relayer les requêtes (ce qui rajoute un intermediaire) et quelques stats pourquoi pas.
    • en quoi la non-modifiabilités du code augmente la sécurité ?
    Personnellement je ne vois qu'un seul réel avantage à l'utilisation de WMCS, c'est de pouvoir utiliser librement des librairies Javascript tiers (c'est possible sur WP mais moins aisée). — 0x010C ~discuter~ 24 mars 2022 à 09:09 (CET)Répondre[répondre]
    Bonjour 0x010C Émoticône
    • Oui c'est vrai, vous avez raison. J'espère que cette possibilité sera prise en compte quel que soit le choix retenu.
    • Corrigez moi si je me trompe, mais le Gadget actuel gère tout le fenêtrage en pur javascript. C'est ce qui explique la dizaine de secondes de temps de chargement pour tout charger en RAM sur le client et lancer l'affichage. C'est à l'heure actuelle, la principale raison qui m'a éloigné de LiveRC, je suppose que je ne suis pas le seul.
    • Si l'outil se base sur l'api et n'implémente aucune forme de sécurité en lui même, pas de problème. Si je révoque avec l'outil et que je n'ai pas le statut de révocateur, rien ne se passe. En revanche, si on décide par exemple qu'il faut être autopatrolled pour simplement utiliser l'outil, c'est quelque chose qui sort du cadre de l'api et qui devra être implémenté dans l'outil, dont le code javascript se trouvera, modifiable, sur le poste client.
    C'est un point de vue extérieur. Peut-être que je fais des suppositions erronées dans ma description, je veux bien en discuter. ίᖆᘺᙅ @#! 24 mars 2022 à 10:05 (CET)Répondre[répondre]
    Je ne vais pas trop m'étendre sur cette page publique, mais je viens de faire quelques tests sur ce que je soupçonnais et il y a définitivement un problème de sécurité sur le LiveRC actuel. ίᖆᘺᙅ @#! 24 mars 2022 à 17:36 (CET)Répondre[répondre]
    Ce n'est pas le temps de rendu de l'interface qui ralentit le démarrage de l'actuel LiveRC, ce sont les dizaines de requêtes à l'API qu'il fait pour récupérer la liste des admins, des bots, des IP scolaires, des IPs partagées, des proxys ouverts, etc. --Golmote (discuter) 25 mars 2022 à 19:28 (CET)Répondre[répondre]
    (Je fais des suppositions. Merci, c'est bien de me corriger quand je me trompe) Dans ce cas, une application qui précache coté serveur toutes ces données pour les envoyer au client immédiatement et en une seule fois pourrait probablement améliorer le temps de chargement par rapport au widget actuel qui demande à chaque client de faire ses dizaines (?) de requêtes avant de commencer. ίᖆᘺᙅ @#! 25 mars 2022 à 21:39 (CET)Répondre[répondre]
    Avec WMCS, l'interface sera rendu en HTML qui sera chargée directement puis la mise à jour se fera en AJAX (JavaScript). Avec le gadget, il faut générer toute l'interface en modifiant le DOM.
    Dans les 2 cas, rien n'interdit à l'utilisateur de « cloner » le programme et de le modifier pour faire « sauter » les limitations. L'important est surtout de faire en sorte que l'utilisateur « de base » n'aille pas à l'encontre des pratiques de sa communauté sans faire exprès et que le programme ne puisse pas être exploiter pour un vol/usurpation de compte. Sur ce point, je pense que les 2 solutions se valent.— Gratus (discuter) 25 mars 2022 à 17:17 (CET)Répondre[répondre]
    Il y a pourtant une différence essentielle. Si on compare LiveRC et SWviewer, on voit que l'un est disponible pour tout le monde alors que l'autre utilise Oauth en amont ce qui interdit l'accès au code à l'utilisateur "de base". Certes, rien n'empêche quelqu'un de récupérer le code de SWviewer, qui est libre, et de l'installer sur son propre serveur, et effectivement cela reste hors de portée de la plupart des gens. Mais ça implique que même si une personne le fait, elle sera la seule à en bénéficier. En revanche, il faudrait 5 minutes à un utilisateur "de base" pour avoir accès aux fonctions de LiveRc en suivant les instructions extrêmement simples que je lui donnerais pour y parvenir. Personellement, je vois dans cette solution un potentiel de nuisance énorme. ίᖆᘺᙅ @#! 25 mars 2022 à 19:34 (CET)Répondre[répondre]
    Franchement, le potentiel de nuisance (volontaire) par simple accès à LiveRC est quasi nul : il y a des moyens à la fois plus simples/accessibles et surtout beaucoup plus « efficaces » de dégrader WP. La limitation de l'accès à LiveRC a pour seul but d'éviter que des petits nouveaux fassent joujou avec sans maîtriser les règles (rien à voir avec des nuisances volontaires). — Jules* discuter 25 mars 2022 à 19:57 (CET)Répondre[répondre]
    Par "pouvoir de nuisance", je voulais bien dire ce qu'il est possible de faire. Ensuite que ce soit peu probable je le conçois tout à fait mais ce n'est pas la même chose. Ici, je justifiais juste le (+) et le (-) que j'ai ajouté. Il y a une solution qui est objectivement plus sure que l'autre (parce que la sécurité se fait coté serveur), mais ça n'empêche pas ensuite de ne pas la choisir. Il faut cependant avoir conscience des différences pour bien choisir. — Le message qui précède, non signé, a été déposé par Irwc (discuter)
    Bonjour à tous Émoticône sourire
    Pardonnez-moi pour cette première intervention fort tardive et très peu informée alors que vous êtes tous impliqués depuis plusieurs mois déjà… mais mieux vaut tard qu'encore plus tard (j'imagine)…
    Merci d'avoir ouvert cette section sur le sujet important de l'environnement technique — beaucoup plus important qu'il n'y paraît probablement au premier abord, en particulier aux utilisateurs qui ne participent pas au développement.
    Je pense en effet qu'une des raisons principales pour la stagnation de LiveRC depuis des années tient dans le fait qu'il est développé on-wiki avec des outils complètement inappropriés : éditeur de code dans le navigateur, tout le code source à un seul endroit, impossibilité d'utiliser sans contorsions les outils que n'importe quel développeur devrait être en droit de considérer comme acquis en 2022 (éditeur de texte, linter, debugger, gestionnaire de versions, intégration continue…).
    En suivant l'intuition louable de laisser l'outil modifiable à tout le monde (noté « (+) Le logiciel peut être modifié directement sur Wikipédia » au-dessus), on est arrivé à une situation où non seulement les non-développeurs parmi les rares administrateurs d'interface n'arrivent pas à contribuer à l'outil, mais où en plus les développeurs eux-mêmes n'y arrivent plus non plus, ou au prix d'efforts sans commune mesure avec la nature des améliorations apportées et avec un risque permanent de casser quelque chose (NB: c'est vrai pour tous les gadgets, LiveRC n'est qu'un cas parmi les autres).
    Un bon moyen d'avoir un LiveRC 2.0 d'une bien meilleure qualité logicielle que LiveRC 1.0 serait d'utiliser et de permettre d'utiliser les outils suivants :
    • un gestionnaire de versions (et tant qu'à faire celui qui est largement dominant dans l'industrie et la communauté Wikimedia : git) ;
    • un outil de revue de code (et pourquoi pas un déjà utilisé par la communauté Wikimedia : gerrit) ;
    • une intégration continue avec des tests pour s'assurer qu'une modification ne casse rien avant de la passer en production.
    L'utilisation de ces outils serait dans l'absolu compatible avec les deux modes de déploiement, mais elle serait bien plus naturelle et facile à mettre en œuvre avec un déploiement sur WMCS (sur Toolforge, plus précisément).
    Le gain en termes de sécurité contre des actions malicieuses n'est guère plus que théorique, les administrateurs d'interface ayant toujours, avec ou sans LiveRC, la possibilité d'abuser des droits des autres utilisateurs. Par ailleurs, le code déployé sur Toolforge est moins auditable que celui déployé sur un wiki (impossible de cacher complètement un code malicieux sur le wiki : il y aura toujours des traces dans l'historique des modifications).
    Un gain en termes de performances n'est pas exclu, mais il n'est pas garanti non plus. Ce qui pourrait être plus performant grâce à Toolforge :
    • toutes les ressources pourraient être minifiées et compressées de façon optimale (la dernière fois que je me suis penché sur ResourceLoader, le chargement de ressources secondaires et / ou cross-wiki n'était encore pas géré — prenez ce point avec des pincettes, ça date un peu) ;
    • un filtrage des données à transférer vers le client LiveRC pourrait être fait côté serveur (la meilleure source de données pour LiveRC serait probablement EventStreams, mais sauf à réussir à y contribuer un langage de requêtage plus expressif que l'actuel, un pré-filtrage côté serveur pourrait sensiblement améliorer les performances pour les utilisateurs n'ayant pas une connexion internet particulièrement rapide et / ou stable) ;
    • les données récupérées au lancement de LiveRC (liste des admins, des bots…) pourraient être mises en cache sur le serveur et servies avec le payload HTML initial.
    Ce qui pourrait être moins performant sur Toolforge :
    • un filtrage des données à transférer vers le client LiveRC ajouterait de la latence pour les utilisateurs qui ont une bonne connexion internet (par l'existence de cette étape intermédiaire, mais aussi parce que si les principaux services Wikimedia sont fournis par les datacenters les plus proches de l'utilisateur — par exemple par Esams et Drmrs en Europe — les services WMCS et donc Toolforge sont systématiquement fournis depuis les datacenters principaux — c'est-à-dire Eqiad et Codfw en Amérique du Nord).
    Accessoirement, si l'obtention de financements devait permettre de faire intervenir une main d'œuvre non-issue de la communauté Wikimedia, je pense qu'il faut définitivement voir l'hébergement on-wiki comme un frein aux contributions.
    Amicalement — Arkanosis 2 avril 2022 à 22:52 (CEST)Répondre[répondre]
    Merci pour ce commentaire très détaillé et éclairant, Arkanosis ; l'option Toolforge semble clairement à privilégier, au vu de l'ensemble des éléments ci-dessus, à mes yeux de profane. — Jules* discuter 2 avril 2022 à 23:31 (CEST)Répondre[répondre]

    Calendrier du projet[modifier le code]

    Hello,

    Histoire de cadrer un peu les choses, j'ai proposé un calendrier prévisionnel, tant pour l'étape courante (élaboration de la V2 du cahier des charges) que pour les suivantes : Wikipédia:Patrouille RC/Projet LiveRC 2.0#Comment ?.

    Vos retours sont les bienvenus. — Jules* discuter 27 mars 2022 à 13:14 (CEST)Répondre[répondre]

    Je suis malade (rien de grave), donc je ne peux pas commencer la synthèse tout de suite, mais dès que je suis requinqué, je m'y mets Émoticône.
    Jules* discuter 4 avril 2022 à 19:38 (CEST)Répondre[répondre]

    badge[modifier le code]

    ce n'est pas en rapport avec le développement du projet mais pourrait-t-on créer un badge pour sa page d'utilisateur avec un logo LiveRC 2.0|bulle participer au projet live RC 2.0 et un lien vers la page. j'ai essayé en suivant les consignes données mais sur une page de création mais le lien ne marchait pas. PS j'ai déjà créé une boiteLoïs Wahl(laisse moi un message) 28 mars 2022 à 13:01 (CEST)Répondre[répondre]

    Vers la V2[modifier le code]

    Hello,

    Merci beaucoup à celles et ceux (enfin surtout ceux : pas beaucoup de mixité ici hélas ><) qui ont participé à l'élaboration de la deuxième itération du cahier des charges Émoticône sourire. Je vous notifie, puisque ce qui suit concerne la finalisation de la v2 du cahier des charges. @Qwerty1999, @Arkanosis, @Irwc, @Gpesenti, @Golmote, @Hyméros, @Gratus, @LucienB49, @Loïs_WAHL et @Martin-78, @JackJackpot, @Trizek et @Aymeric50800.

    Si vous souhaitez ne plus être notifiés à l'avenir, n'hésitez pas à me le dire : je ne veux pas vous harceler Émoticône.

    Bilan des réponses aux questions

    Je ne reviens pas en détail sur les réponses aux questions sur les usages actuels de LiveRC, qui ne sont pas étonnantes. A priori, pas trop de demande pour intégrer ces éléments dans LiveRC 2.0 (plusieurs d'entre eux complexifient nécessairement l'interface).

    Pour la patrouille cross-wiki, il n'y a que deux avis, pas tout à fait concordants ; on avancera sans doute avec l'avis des autres communautés linguistiques, mais si le développement de l'affichage cross-wiki n'est pas trop gourmand en temps et qu'il y a une demande, c'est à envisager sérieusement. C'est un point qui reste en suspens, donc.

    Pour le statut nécessaire pour utiliser le logiciel, les avis vont de autopatrolled à révocateur ; il faudra donc que ces deux options (a minima) soient disponibles et que chaque wiki puisse configurer ça. À voir comment ça peut se goupiller en cross-wiki le cas échéant (faut-il remplir les conditions d'utilisation locales de chacun des wikis sur lesquels on veut patrouiller... pour ceux qui ont défini ? à voir dans la prochaine itération du cahier des charges).

    Enfin, je pense sage de s'orienter vers le développement d'une interface modulaire (option B) plutôt que vers une interface mobile, notamment pour les raisons indiquées par Arkanosis, sans arrêter définitivement notre choix maintenant.

    J'intègre tout ça dans la V2 du cahier des charges, sur la page principale.

    Bilan des suggestions

    Quant aux autres éléments, j'ai intégrés ceux consensuels directement dans la V2 du cahier des charges, sur la page principale. Plusieurs suggestions n'ont pas été plussoyées, donc j'ai considéré par défaut qu'il ne s'agissait pas de besoins partagés/consensuels, mais il n'est pas trop tard pour en rediscuter si vous le souhaitez :

    • Affichage des diffs non chronologique
    • Option Recherche
    • Équivalent de DiffExtension (est-ce à intégrer au projet ou hors périmètre ?)
    Environnement technique

    Au vu de ce qu'a détaillé Arkanosis, s'orienter vers un logiciel hébergé sur Toolforge semble à privilégier.

    Validation de la V2 et étape suivante

    Vérifiez que je n'ai rien oublié et que la V2 correspond bien aux consensus qui se sont dégagés ; modifiez directement si besoin. Une fois que cette V2 sera validée, on passera à la traduction en anglais, afin de pouvoir la soumettre aux autres communautés linguistiques.

    Jules* discuter 8 avril 2022 à 13:45 (CEST)Répondre[répondre]

    Bonjour Émoticône
    Merci pour tout ce travail ! Pour moi tout a l'air bon dans la V2. --Martin-78 (discutailler) 8 avril 2022 à 14:44 (CEST)Répondre[répondre]
    Bonsoir,
    Merci pour cette nouvelle version. Tout me semble également bon. — RG067 (discuter) 8 avril 2022 à 22:04 (CEST)Répondre[répondre]
    Pareil pour moi. Vivement l'approbation Loïs Wahl(laisse moi un message) 11 avril 2022 à 12:59 (CEST)Répondre[répondre]
    Rien à ajouter. Super boulot, bravo ! — LucienB Allo ? 12 avril 2022 à 17:23 (CEST)Répondre[répondre]
    Bon, super, passons à l'étape suivante ; j'ouvre une section pour la traduction en anglais. — Jules* discuter 15 avril 2022 à 21:37 (CEST)Répondre[répondre]
    Bonsoir Émoticône
    Je redécouvre, en le traduisant, le cahier des charges. Un des reproches faits à la version actuelle de LiveRC est « une interface très chargée, liens très petits avec risques de missclik, etc. ». Or il me semble que dans ce même cahier des charges, dans la partie Un composant d'aperçu des diffs, nous demandons l'affichage de beaucoup d'informations. Si toutes nos demandes sont exaucées, je vois difficilement comment nous pourrions ne pas nous retrouver avec la même interface surchargée de l'actuel LiveRC.
    Amicalement, --JackJackpot (devisons) 24 avril 2022 à 00:29 (CEST)Répondre[répondre]

    Pour plus de visibilité[modifier le code]

    Bonsoir Émoticône

    Pour plus de visibilité entre les différentes itérations du cahier des charges, ne voudriez-vous pas créer des onglets (un par itération), comme sur la PU de notre ami @Jules* ?

    Personnellement, je me perds un peu entre la V1 et la V2...

    Amicalement, --JackJackpot (devisons) 11 avril 2022 à 17:39 (CEST)Répondre[répondre]

    Hello @JackJackpot. Je regarde plus tard comment faire ça, mais en attendant :
    • la V1 est  ;
    • la V2 est (et toutes les différences avec la V1 sont indiquées en vert).
    Bien à toi ! — Jules* discuter 13 avril 2022 à 00:22 (CEST)Répondre[répondre]
    @JackJackpot, ton souhait est exaucé : Wikipédia:Patrouille RC/Projet LiveRC 2.0/Cahier des charges. — Jules* discuter 15 avril 2022 à 21:36 (CEST)Répondre[répondre]
    Merci Jules* Émoticône, c'est parfait ! --JackJackpot (devisons) 16 avril 2022 à 08:16 (CEST)Répondre[répondre]

    Traduction en anglais[modifier le code]

    Hello,

    La V2 étant validée, il faut maintenant la traduire, ainsi que la présentation du projet, en anglais. Le but : que les wikipédiens d'autres versions linguistiques puissent en prendre connaissance et faire leurs suggestions. Autrement dit, c'est un préalable à leur démarchage.

    Concrètement, j'ai créé le réseau de sous-pages pour la traduction. Il y a deux pages à traduire (j'ai déjà mis le texte à traduire) et votre aide est la bienvenue. Mettez le bandeau {{en cours}} dans la section que vous traduisez, histoire de ne pas être plusieurs à traduire la même chose en même temps.

    Amicalement, — Jules* discuter 15 avril 2022 à 21:44 (CEST)Répondre[répondre]

    Comme l'utilisation de l'historique ou la navigation entre la version française et la version anglaise me semble peu pratique pour comparer ces dernières, j'ai une suggestion supplémentaire : ne pas écraser le texte traduit mais garder les deux versions, française et anglaise, en mettant la deuxième en bleu (ou une autre couleur, à voir), afin de faciliter les travaux de relecture et améliorations entre les différents traducteurs.
    Amicalement, --JackJackpot (devisons) 16 avril 2022 à 08:30 (CEST)Répondre[répondre]
    Ok, j'ai rien dit. Avec les listes ça rend le code très vite indigeste... --JackJackpot (devisons) 16 avril 2022 à 12:49 (CEST)Répondre[répondre]
    Merci beaucoup à @JackJackpot qui a beaucoup traduit. N'hésitez pas à relire. Il reste aussi à traduire Wikipédia:Patrouille RC/Projet LiveRC 2.0#Comment ?, je le ferai dès que possible ; désolé, j'ai manqué de temps ces derniers jours. — Jules* discuter 22 avril 2022 à 13:54 (CEST)Répondre[répondre]

    Suite du projet : question @tous[modifier le code]

    ✔️ Bon, voilà, traduction terminée (encore merci JackJackpot). Des relectures sont néanmoins toujours les bienvenues (cf. section ci-dessus).

    Concernant le planning : je vais être franc, la semaine prochaine je n'aurai pas trop le temps de gérer le projet, et ensuite je pars une semaine en vacances, jusqu'au . Donc deux possibilités :

    • soit l'un(e) (ou plusieurs, n'hésitez pas) d'entre vous prend le relai pour animer tout ça dans les deux-trois semaines à venir (sachant que je viens de détailler les prochaines tâches à effectuer) ;
    • soit le projet reste en plan jusqu'à mon retour Tire la langue.

    Amitiés, — Jules* discuter 29 avril 2022 à 18:38 (CEST)Répondre[répondre]

    Diagramme de classes[modifier le code]

    Projet LiveRC 2.0 - diagramme de classes.png

    Bonjour! Vu que le cahier des charges est déjà bien avancé, j'ai fait un premier jet d'un diagramme de classes pour faire une traduction plus technique.— Gratus (discuter) 30 avril 2022 à 16:55 (CEST)Répondre[répondre]

    Suite ?[modifier le code]

    Bonjour,

    Est-ce que le projet est toujours en cours ?

    --Mathis B discuter, le 17 juin 2022 à 22:59 (CEST)Répondre[répondre]

    Hello @Mathis B. Il était en pause. Pour être franc, ça m'a un peu démotivé d'avoir peu de répondant pour la traduction en anglais (JackJackpot, surtout, et moi avons tout fait tout seuls et personne n'a relu) puis aucune réponse à mon message du 29 avril. Du coup j'attendais de voir si quelqu'un allait relancer (merci de l'avoir fait), mais je comptais quand même m'y remettre dans les jours à venir (fut-ce seul), car le projet me semble vraiment important. Il s'agit de contacter les autres communautés linguistiques, en particulier celles utilisant LiveRC ; ce ne sont clairement pas les étapes les plus « amusantes », mais elles sont nécessaires. — Jules* discuter 17 juin 2022 à 23:08 (CEST)Répondre[répondre]
    Bonsoir Jules* Émoticône
    Ça fait encore peu de monde, mais je reste prêt à aider pour les prochaines étapes.
    Amicalement, --JackJackpot (devisons) 18 juin 2022 à 00:14 (CEST)Répondre[répondre]
    Bonjour,
    Je n'aurais pas beaucoup de temps, mais n'hésitez pas à également me solliciter pour les prochaines étapes. Concernant la traduction en anglais, je ne pense pas que mon niveau dans la langue soit suffisant pour la relire. — RG067 (discuter) 18 juin 2022 à 13:44 (CEST)Répondre[répondre]
    Super ! Merci Émoticône sourire. Je vais commencer une liste des lieux où contacter les autres projets sur Wikipédia:Patrouille RC/Projet LiveRC 2.0#Contacts cross-wiki, et on pourra éventuellement se répartir la prise de contact (avec les membres du projet qui se sentent suffisamment à l'aise en anglais). — Jules* discuter 18 juin 2022 à 16:40 (CEST)Répondre[répondre]
    Bonjour, désolé à tous de ne pas m'investir davantage aussi, cf. commons.
    Le plus simple serait réutiliser cette liste de diffusion (en l'adaptant). Un message-type en anglais serait déjà une bonne initiative (en indiquant que nous ne traduisons pas davantage car c'est une iniative francophone... pas un manque de respect). LD (d) 18 juin 2022 à 16:56 (CEST)Répondre[répondre]
    Merci @LD, je vais croiser ça avec wikidata:Q7027060. Bonne idée pour la liste de diffusion. Sinon, on a déjà tout traduit (cahier des charges et présentation du projet), en fait Émoticône ; sauf les présentes discussions. — Jules* discuter 18 juin 2022 à 17:15 (CEST)Répondre[répondre]
    Méprise, je voulais dire : envoyer un message en anglais, mais pas dans la langue locale (on trouvera difficilement un traducteur sur WP en français pour chaque langue). On peut espérer que localement, ils traduiront de l'anglais (et sans nous en vouloir si on précise que c'est une initiative de la communauté francophone). LD (d) 18 juin 2022 à 17:17 (CEST)Répondre[répondre]

    ┌─────────────────────────────────────────────────┘

    Ah oui. Voici une ébauche de message en anglais, n'hésitez pas à modifier/améliorer :

    « Hi, I'm [user] from Wikipedia in French. Sorry to write in English; if someone can translate in the local language, it would be much appreciated. We plan to develop a new version of LiveRC [lien vers la page locale si elle existe], a patrolling tool that is a lot used on fr-wp to fight vandalism, but that is getting old, outdated, and needs several improvements. The project page is translated in English. The tool is needed for fr-wp, but we want to make it available (and configurable) for other wikis.

    The fr-wp patrolling community has built a specifications list for this new tool, with our needs. We translated this specifications list in English and it's available there.

    We would be happy to get your feedbacks regarding the specifications we wrote, in order to take into account the needs of your community and build, as much as possible, a tool that suits other communities needs. You can post your feedbacks (preferably in English) on the fr-wp talkpage dedicated to it.

    If you reply to this message here, please ping me so I don't miss it. Warm regards, »

    Jules* discuter 18 juin 2022 à 17:59 (CEST)Répondre[répondre]

    Ça me semble très bien au détail près qu'il n'y a pas besoin de majuscule à specifications Émoticône. --Mathis B discuter, le 18 juin 2022 à 18:18 (CEST)Répondre[répondre]
    Corrigé, merci ! — Jules* discuter 18 juin 2022 à 18:38 (CEST)Répondre[répondre]
    Conflit d’édition

    « Hi, I'm [user] from Wikipedia in French. Sorry to write in English; if someone can translate in the local language, it would be much appreciated. We plan to develop a new version of LiveRC [lien vers la page locale si elle existe], a patrolling tool commonly used on fr-wp to fight vandalism, but it is getting old, outdated, and needs several improvements. The project page is translated in English. The tool is needed for fr-wp, but we want to make it available (and configurable) for other wikis.

    The fr-wp patrolling community has built a list of specifications for this new tool with our needs. We translated “Specifications” in English and it's available there.

    Your feedback would be appreciated regarding “Specifications” we wrote, in order to take into account the needs of your community and build, as much as possible, a tool that suits other communities needs. You can post your feedbacks (preferably in English) on the fr-wp talkpage dedicated to it.

    If you reply to this message here, please ping me so I don't miss it. Warm regards, »

    J'ai un bug (récent) qui m'empêche de copier/coller les liens internes (c'est bête), mais je suggère ces modifications (ex. tournures principalement passives en anglais). LD (d) 18 juin 2022 à 18:44 (CEST)Répondre[répondre]

    ┌─────────────────────────────────────────────────┘
    Bon j'ai mergé ci-dessous les versions de @Jules* et @LD :

    « Hi, I'm [user] from Wikipedia in French. Sorry to write in English; if someone can translate in the local language, it would be much appreciated. We plan to develop a new version of LiveRC [lien vers la page locale si elle existe], a patrolling tool commonly used on fr-wp to fight vandalism, but it is getting old, outdated, and needs several improvements. The project page is translated in English. The tool is needed for fr-wp, but we want to make it available (and configurable) for other wikis.

    The fr-wp patrolling community has built a list of specifications for this new tool with our needs. We translated “Specifications” in English and it's available there.

    Your feedback would be appreciated regarding “Specifications” we wrote, in order to take into account the needs of your community and build, as much as possible, a tool that suits other communities needs. You can post your feedbacks (preferably in English) on the fr-wp talkpage dedicated to it.

    If you reply to this message here, please ping me so I don't miss it. Warm regards, »

    My two pences : dans la mesure où on ne passe pas l'agreg d'anglais, je pense qu'on peut se satisfaire de cette version qui est très bien, même si avec nos sensibilités respectives, on aurait peut-être fait chacun quelques petites retouches. Je pense que l'objectif de se faire comprendre est largement atteint Émoticône sourire. Amicalement, --JackJackpot (devisons) 21 juin 2022 à 07:02 (CEST)Répondre[répondre]

    Je pense aussi qu'on peut partir sur cette version avec les corrections de @LD Émoticône. — Jules* discuter 21 juin 2022 à 12:33 (CEST)Répondre[répondre]
    Hello. J'ai complété le tableau. Nous sommes techniquement prêts à lancer le truc. Je propose de le faire dans les jours à venir (sachant que perso je serai absent du 7 au 14) et de laisser les mois de juillet et août pour la réception des retours des autres communautés. Ainsi, à la rentrée, nous pourrons voir avec Wikimédia France pour la suite des opérations (financement, développement). — Jules* discuter 2 juillet 2022 à 15:36 (CEST)Répondre[répondre]
    Bon, ben j'ai pas eu le temps (déménagement IRL, etc.). Pas trop grave dans la mesure où ce sont les vacances. Je publie ça sans faute le 30 ou le 31, mais il faudra sans doute relancer sur les différents wiki début septembre. Et j'espère qu'en septembre nous pourrons redynamiser le projet. — Jules* discuter 28 juillet 2022 à 18:17 (CEST)Répondre[répondre]
    Bonsoir Jules* Émoticône
    Dans la mesure où on est plus à un mois près, je serais plutôt d'avis d'attendre septembre pour solliciter les autres communautés :
    • je ne connais pas très bien les lois concernant les congés payés (ou non payés) dans les autres pays, mais je ne serais pas surpris que les contributeurs des autres wikis qui peuvent partir en vacances le fassent pendant l'été.
    • de notre côté, après avoir sollicité les autres communautés, il serait préférable que nous soyions là pour répondre aux éventuelles questions.
    Mais puisque tu portes le projet, je te fais confiance Émoticône sourire.
    Amicalement, --JackJackpot (devisons) 28 juillet 2022 à 23:24 (CEST)Répondre[répondre]
    Hello ! Je m'étais posé la question, mais vu ton message @JackJackpot (merci), faisons ainsi alors : attendons septembre Émoticône sourire. Si ça permet de poursuivre proprement le projet, ça vaut le coup d'attendre. Amicalement, — Jules* discuter 29 juillet 2022 à 08:46 (CEST)Répondre[répondre]
    Bonjour à tous.
    j'étais en wiki slow du fait des vacances.
    nous somme actuellement en septembre et je pense que l'on pourrait solliciter les autres communauté.
    j'ai aussi un niveaux équivalent à B2,C1 (ma mère était prof d'anglais) en anglais je pourrais donc vous êtres utiles. à la bonne continuation de ce projet. je guetterait les avancés de cette page.
    Loïs Wahl(laisse moi un message) 22 septembre 2022 à 11:01 (CEST)Répondre[répondre]
    Hello ! J'attendais un message tiers pour relancer la machine ; merci @Loïs WAHL Émoticône. Les messages étant prêts, il suffit de décider quel jour on les publie sur les différents wiki, et ensuite il faudra assurer le suivi des réponses. On publie ce week-end ? @JackJackpot et @Mathis B et tout le monde ? — Jules* discuter 22 septembre 2022 à 19:29 (CEST)Répondre[répondre]
    Salut. Je m'occuperais de wp-zh sur zh:Wikipedia:互助客栈/消息 Émoticône, je peux aussi essayer de suivre zh-classical (zh-classical:維基大典:會館) mais je n'ai appris que les sinogrammes simplifiés (mais cela ne devrait pas trop poser problème, la plupart des contributeurs zh-classical lisent les deux formes et l'anglais y est aussi présent). LD (d) 22 septembre 2022 à 20:22 (CEST)Répondre[répondre]
    Salut, pas très présent cette semaine, je rentre dimanche, je vous laisse faire. --Mathis B discuter, le 22 septembre 2022 à 20:22 (CEST)Répondre[répondre]
    @Jules* ouaip, je peux participer. JackJackpot (devisons) 22 septembre 2022 à 22:34 (CEST)Répondre[répondre]

    @Jules* je suis pas la ce weekend mais je vous laisse faire. je pourrais aller voir vite fais sur mon portable Loïs Wahl(laisse moi un message) 23 septembre 2022 à 14:11 (CEST)Répondre[répondre]

    Ben écoutez je commence demain, n'hésitez pas à vous occuper de langues avec lesquelles vous avez des affinités Émoticône. — Jules* discuter 25 septembre 2022 à 23:15 (CEST)Répondre[répondre]
    @Jules* Premier contact fait. Pour qu'on ne se marche pas tous et toutes sur les pieds, il faudrait remplir le tableau au fur et à mesure. Amicalement, JackJackpot (devisons) 26 septembre 2022 à 08:53 (CEST)Répondre[répondre]
    On bide un peu non ? JackJackpot (devisons) 4 octobre 2022 à 22:46 (CEST)Répondre[répondre]
    Carrément, même. Rien de dramatique, cela dit : l'essentiel était d'essayer, pour pouvoir tenir compte des éventuelles demandes d'autres communautés. Mais au fond, pas de raison que les besoins soient radicalement différents d'une communauté à l'autre. Je vais quand même demander à un admin anglophone s'il y a une autre page de wp-en où je puisse mettre le message. — Jules* discuter 5 octobre 2022 à 00:02 (CEST)Répondre[répondre]