Discussion Wikipédia:Patrouille RC/Projet LiveRC 2.0

Projet (Project)

Cahier des charges (Specifications)

Développement (French only)

Discussion (French only)

Talk page (English and other languages)

Création de la page

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 5 février 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)

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)

Envisager de partir de bases existantes

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)

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)

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)

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)

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)

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)

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)

J'ai fait ça, d'autres remarques me viendront surement plus tard. Pour le message sur le BULPAT. Bonne soirée — RG067 (discuter) 10 février 2022 à 18:08 (CET)

Bonjour . 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)

Carrément. — Jules* ^Discuter 11 février 2022 à 13:47 (CET)

Totalement d'accord (d'ailleurs, chez vous aussi C-Helper s'affiche bizarrement parfois?) — RG067 (discuter) 11 février 2022 à 14:21 (CET)

Pas de problèmes particuliers, mais je ne l'utilise pas très souvent. — LucienB ^Allo ? 11 février 2022 à 17:27 (CET)

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)

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)

Suite

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)

Je fais une petite réunion en visio avec les salariés de WMFr le 9 mars prochain pour les introduire à ce projet, et ensuite les discussions passeront par ici . — Jules* ^discuter 4 mars 2022 à 16:22 (CET)

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)

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)

@Jules* Cela me semble être une bonne base de fonctionnement. Il faudra juste penser à traduire notre ébauche avant de contacter les autres communautés . — 0x010C ^~discuter~ 21 mars 2022 à 10:32 (CET)

@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 . — Jules* ^discuter 22 mars 2022 à 13:21 (CET)

J'approuve l'approche, @Jules*

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)

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)

+1 pour les livraisons intermédiaires. — LucienB ^Allo ? 4 avril 2022 à 13:01 (CEST)

Aide

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)

 Gratus : Bonjour,

Une discussion a justement été lancée cette après-midi sur la liste du groupe technique de Wikimédia France dont  Jules* est en copie, je pense qu'on pourrait t'y ajouter sans problème, ping  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)

Nice! — Gratus (discuter) 10 mars 2022 à 03:26 (CET)

 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)

Cahier des charges V1

Bonjour @Hyméros, @RG067, @LucienB49, @User92259453, @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 ! — Jules* ^discuter 22 mars 2022 à 13:01 (CET)

Description du projet

Contexte

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

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

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

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

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

• sur les usages actuels de LiveRC :
  • utilisez-vous la possibilité d'ouvrir les pages, les historiques, etc., directement dans LiveRC ?
    • non — Jules* ^discuter 22 mars 2022 à 19:03 (CET)
    • Rarement, l'interface n'est pas pratique pour cela. Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)
    • Rarement, les liens n'indiquent pas clairement s'ils s'ouvrent dans LiveRC ou non. Dans le doute, j'ouvre tous les liens dans un nouvel onglet pour ne pas risquer de quitter accidentellement LiveRC quand le lien n'est pas géré. --Golmote (discuter) 23 mars 2022 à 20:03 (CET)
    • Idem, un crtl-clic raté et paf, LiveRC saute. --Hyméros ^{--}-≽ ♥} 23 mars 2022 à 23:30 (CET)
    • De temps en temps pour l'Historique, rarement pour les autres. — LucienB ^Allo ? 24 mars 2022 à 13:12 (CET)
    • juste pour voir si des modifications suspecte sont du vandalisme mais la plupart du temps j'ouvre dans un autre onglet. Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:06 (CET)
    • Très rarement. --Martin-78 ^{(discutailler)} 26 mars 2022 à 10:52 (CET)
    • Jamais dans LiveRC, mais très souvent depuis LiveRC — Arkanosis ^✉ 2 avril 2022 à 23:07 (CEST)
    • Si l'interface signale que l'article a fait l'objet de modifications enchainés, il peut m'arriver de consulter l'historique. Mais sinon pas de mémoire. — Juju ^{[💬 Discuter]}, le 9 avril 2022 à 22:18 (CEST)
  • modifiez-vous des pages directement dans LiveRC ?
    • non — Jules* ^discuter 22 mars 2022 à 19:03 (CET)
    • non Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)
    • non --Golmote (discuter) 23 mars 2022 à 20:03 (CET)
    • non. J'ouvre dans un autre onglet (clic sur le titre de l'article) pour effectuer toutes opérations qui n'est pas explicitement supportée par LIVE RC.— Gratus (discuter) 23 mars 2022 à 23:24 (CET)
    • nop --Hyméros ^{--}-≽ ♥} 23 mars 2022 à 23:30 (CET)
    • Rarement — LucienB ^Allo ? 24 mars 2022 à 13:12 (CET)
    • jamais Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:11 (CET)
    • Non. --Martin-78 ^{(discutailler)} 26 mars 2022 à 10:52 (CET)
    • Jamais — Arkanosis ^✉ 2 avril 2022 à 23:07 (CEST)
    • Jamais aussi. — Juju ^{[💬 Discuter]}, le 9 avril 2022 à 22:18 (CEST)
  • utilisez-vous la fonctionnalité de suivi des utilisateurs / contacts fournie par LiveRC ?
    • non — Jules* ^discuter 22 mars 2022 à 19:03 (CET)
    • non Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)
    • rarement --Golmote (discuter) 23 mars 2022 à 20:03 (CET)
    • Pas sûr de savoir de quoi on parle. S'il s'agit de la fonctionnalité qui indique si un utilisateur a déjà été reverté recemment, c'est utile pour suivre un vandale en série en attendant le blocage.— Gratus (discuter) 23 mars 2022 à 23:24 (CET)

      Hello @Gratus. Non, il s'agit du petit « W » à gauche du nom de l'utilisateur ou de l'IP, dans la liste des RC. Bàt, — Jules* ^discuter 24 mars 2022 à 08:27 (CET)

    • Utile, mais rarement utilisé car peu pratique (visible). --Hyméros ^{--}-≽ ♥} 23 mars 2022 à 23:30 (CET)
    • Non — LucienB ^Allo ? 24 mars 2022 à 13:12 (CET)
    • Jamais comme 'Gratus je me sert souvent de l'outil pour savoir si un utilisateur à été révoc il y a peu de temps. à garder sur la nouvelle version.
    • Non --Martin-78 ^{(discutailler)} 26 mars 2022 à 10:52 (CET)
    • Non — Arkanosis ^✉ 2 avril 2022 à 23:07 (CEST)
    • Pas de mémoire. — Juju ^{[💬 Discuter]}, le 9 avril 2022 à 22:18 (CEST)
• 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)
    • 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)
  • 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)
    • Le bon niveau serait autopatrolled pour utiliser toutes les fonctionnalités, d'après moi. — RG067 (discuter) 22 mars 2022 à 18:51 (CET)
    • D'accord avec RG067. --Golmote (discuter) 23 mars 2022 à 20:01 (CET)
    • Je propose de placer « autoconfirmed » avec un fichier de configuration « protégé » permettant à chaque communauté linguistique de limiter les accès selon leurs processsus de prise de décision.— Gratus (discuter) 23 mars 2022 à 23:24 (CET)
    • D'accord avec RG067 et Golmote. — LucienB ^Allo ? 24 mars 2022 à 13:22 (CET)
    • d'accrod avec @RG067 et @Gratus Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:11 (CET)
    • nécéssité selon moi d'avaoir le statut de révocateur/révocatrice pour, justement, révoquer d'un coup plusieurs modif. Il ne faut pas que l'outil soit un moyen de bypasser l'étape d'obtention du statut de révocateur/trice. --JackJackpot (devisons) 2 avril 2022 à 16:45 (CEST)

      Hello @JackJackpot : pour info c'est déjà possible (et ça le sera toujours) avec LiveRC et certains gadgets. — Jules* ^discuter 2 avril 2022 à 17:18 (CEST)

    • Je rejoins bien évidemment RG067. — Juju ^{[💬 Discuter]}, le 9 avril 2022 à 22:18 (CEST)
  • 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)
    • D'accord avec Jules et ses réserves d'une utilisation sur mobile. — LucienB ^Allo ? 24 mars 2022 à 13:22 (CET)
    • 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)

    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)

    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)

    • 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)
    • 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)
    • B sans hésitation. --Hyméros ^{--}-≽ ♥} 4 avril 2022 à 18:46 (CEST)
    • 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)

Discussions

• 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)
• 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)
• 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)

  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)

  ok. c'était pas explicite pour moi Bertold Brecht ^{>dissoudre le peuple<} 22 mars 2022 à 18:59 (CET)

• 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)

  +1, permet un meilleur suivi. Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)

  +1, important pour le suivi. — LucienB ^Allo ? 24 mars 2022 à 13:41 (CET)

  +1, très pratique pour le suivi Loïs Wahl(laisse moi un message) 25 mars 2022 à 15:23 (CET)

  +1 --Hyméros ^{--}-≽ ♥} 4 avril 2022 à 18:51 (CEST)

• 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)

  +1, bien vu ! — Jules* ^discuter 22 mars 2022 à 19:02 (CET)

  +1 Qwerty1999 (discuter) 22 mars 2022 à 21:40 (CET)

  +1 — LucienB ^Allo ? 24 mars 2022 à 13:41 (CET)

  +1 --Hyméros ^{--}-≽ ♥} 4 avril 2022 à 18:51 (CEST)

• 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)

Tout à fait d'accord. C'est d'ailleurs le premier problème de LiveRC à mon sens. — Jules* ^discuter 23 mars 2022 à 19:54 (CET)

À 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)

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)

• 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)

@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)

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)

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)

@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)

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)

• 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)

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)

Bonjour Jules** . 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)

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)

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)

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)

@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)

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)

• 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)

• 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)

• 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 (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)

ok @Jules*Loïs Wahl(laisse moi un message) 25 mars 2022 à 16:03 (CET)

• É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)

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)

• 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)

Logique. — Jules* ^discuter 2 avril 2022 à 14:40 (CEST)

• 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)

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)

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)

Retour d’Aymeric50800

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

Miaou Jules*  !

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)

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 ). S'agissant de l'hébergement sous forme de gadget, pourquoi le préfères-tu ? — Jules* ^discuter 2 avril 2022 à 20:19 (CEST)

D’accord, je vais faire ça, et t’invite du coup à répondre là-bas .

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)

Environnement technique

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)

Comme je le dis en discussion, l'outil hébergé me semble plus indiqué. ίᖆᘺᙅ ^@#! 24 mars 2022 à 00:50 (CET)

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)

Bonjour 0x010C

• 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)

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)

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)

(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)

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)

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)

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)

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

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)

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)

Calendrier du projet

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)

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 .
— Jules* ^discuter 4 avril 2022 à 19:38 (CEST)

badge

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)

Vers la V2

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 . 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 .

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)

Bonjour

Merci pour tout ce travail ! Pour moi tout a l'air bon dans la V2. --Martin-78 ^{(discutailler)} 8 avril 2022 à 14:44 (CEST)

Bonsoir,

Merci pour cette nouvelle version. Tout me semble également bon. — RG067 (discuter) 8 avril 2022 à 22:04 (CEST)

Pareil pour moi. Vivement l'approbation Loïs Wahl(laisse moi un message) 11 avril 2022 à 12:59 (CEST)

Rien à ajouter. Super boulot, bravo ! — LucienB ^Allo ? 12 avril 2022 à 17:23 (CEST)

Bon, super, passons à l'étape suivante ; j'ouvre une section pour la traduction en anglais. — Jules* ^discuter 15 avril 2022 à 21:37 (CEST)

Bonsoir

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)

Pour plus de visibilité

Bonsoir

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)

Hello @JackJackpot. Je regarde plus tard comment faire ça, mais en attendant :

• la V1 est là ;
• la V2 est là (et toutes les différences avec la V1 sont indiquées en vert).

Bien à toi ! — Jules* ^discuter 13 avril 2022 à 00:22 (CEST)

@JackJackpot, ton souhait est exaucé : Wikipédia:Patrouille RC/Projet LiveRC 2.0/Cahier des charges. — Jules* ^discuter 15 avril 2022 à 21:36 (CEST)

Merci Jules* , c'est parfait ! --JackJackpot (devisons) 16 avril 2022 à 08:16 (CEST)

Traduction en anglais

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.

• Wikipédia:Patrouille RC/Projet LiveRC 2.0/Cahier des charges/Version 2/en
• Wikipédia:Patrouille RC/Projet LiveRC 2.0/en

Amicalement, — Jules* ^discuter 15 avril 2022 à 21:44 (CEST)

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)

Ok, j'ai rien dit. Avec les listes ça rend le code très vite indigeste... --JackJackpot (devisons) 16 avril 2022 à 12:49 (CEST)

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)

Suite du projet : question @tous

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 14 mai. 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 .

Amitiés, — Jules* ^discuter 29 avril 2022 à 18:38 (CEST)

Diagramme de classes

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)

Suite ?

Bonjour,

Est-ce que le projet est toujours en cours ?

--Mathis B ^discuter, le 17 juin 2022 à 22:59 (CEST)

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)

Bonsoir Jules*

Ç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)

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)

Super ! Merci . 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)

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)

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  ; sauf les présentes discussions. — Jules* ^discuter 18 juin 2022 à 17:15 (CEST)

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)

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

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)

Ça me semble très bien au détail près qu'il n'y a pas besoin de majuscule à specifications . --Mathis B ^discuter, le 18 juin 2022 à 18:18 (CEST)

Corrigé, merci ! — Jules* ^discuter 18 juin 2022 à 18:38 (CEST)

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)

┌─────────────────────────────────────────────────┘
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 . Amicalement, --JackJackpot (devisons) 21 juin 2022 à 07:02 (CEST)

Je pense aussi qu'on peut partir sur cette version avec les corrections de @LD . — Jules* ^discuter 21 juin 2022 à 12:33 (CEST)

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)

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)

Bonsoir Jules*

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 .

Amicalement, --JackJackpot (devisons) 28 juillet 2022 à 23:24 (CEST)

Hello ! Je m'étais posé la question, mais vu ton message @JackJackpot (merci), faisons ainsi alors : attendons septembre . Si ça permet de poursuivre proprement le projet, ça vaut le coup d'attendre. Amicalement, — Jules* ^discuter 29 juillet 2022 à 08:46 (CEST)

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)

Hello ! J'attendais un message tiers pour relancer la machine ; merci @Loïs WAHL . 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)

Salut. Je m'occuperais de wp-zh sur zh:Wikipedia:互助客栈/消息 , 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)

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)

@Jules* ouaip, je peux participer. JackJackpot (devisons) 22 septembre 2022 à 22:34 (CEST)

@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)

Ben écoutez je commence demain, n'hésitez pas à vous occuper de langues avec lesquelles vous avez des affinités . — Jules* ^discuter 25 septembre 2022 à 23:15 (CEST)

@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)

On bide un peu non ? JackJackpot (devisons) 4 octobre 2022 à 22:46 (CEST)

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)

@JackJackpot : Bon, je n'ai pas eu de réponse.

On prévient Wikimédia France que nous n'avons pas reçu de retour des autres communautés et que de notre côté, nous sommes prêts à avancer sur le projet ? Sachant que les étapes suivantes nécessitent l'aide de WMFr (retouches/mise en forme du cahier des charges, appel d'offre...).

Amicalement, — Jules* ^discuter 30 octobre 2022 à 16:12 (CET)

Bonjour Jules* ,

Au moins on aura essayé. Je suis d'avis de passer à l'étape suivante.

Amicalement, JackJackpot (devisons) 1 novembre 2022 à 12:27 (CET)

Bon, j'ai envoyé un courriel à @Rémy Gerbet WMFr, @Naphsica Papanicolaou WMFr, @Arkanosis, @Mathis B et @Jitrixis pour résumer ce que nous avions fait (cahier des charges) et ce qui avait échoué (retour des autres wikis), et pour indiquer que nous étions prêts à avancer. J'ai précisé qu'il serait bon que les échanges se poursuivent ici pour la parfaite information de tout le monde. — Jules* ^discuter 1 novembre 2022 à 16:01 (CET)

 Jules* : pas reçu, l'as-tu bien envoyé à mathis.benguiguiwikimedia.fr ? --Mathis B ^discuter, le 1 novembre 2022 à 16:19 (CET)

Corrigé ! Sorry. — Jules* ^discuter 1 novembre 2022 à 16:24 (CET)

Point d'avancement

Bonjour,

J'ai mis à jour le calendrier du projet sur la page principale, voici les principaux éléments :

• J'ai profité de la WikiConvention francophone ce weekend pour faire avancer le projet, avec deux réunions informelles :
  • La première avec Rémy Gerbet, directeur exécutif de Wikimédia France, Michaël Barbereau, administrateur système et réseau, Jitrixis (d · c · b), membre du conseil d'administration, ainsi qu'Ash Crow (d · c · b) et Poslovitch (d · c · b), qui se sont joint à nous pour leurs compétences techniques. La conclusion a été qu'il nous fallait détailler le cahier des charges communautaire et en faire un macro-chiffrage pour avoir une estimation de budget.
  • La deuxième est ce macro-chiffrage, Ash Crow, Poslovitch et moi-même avons pris 1 h 30 pour le faire, et en sommes ressortis avec un budget. Je ne le donnerai pas publiquement pour ne pas que les répondants à l'appel d'offre s'en servent, l'objectif étant aussi de le confronter à leurs propositions commerciales, mais il semble raisonnable.
• Les prochaines étapes sont :
  • La soumission de ce projet au conseil d'administration, puisque ce développement n'est pas budgetté actuellement.
  • La mise en place d'un comité de pilotage du projet, composé de membres du conseil d'administration, de membres du groupe tech de Wikimédia France et de contributeurs volontaires. Si vous souhaitez en faire partie, je vous propose de me contacter par courriel à l'adresse mathis.benguiguiwikimedia.fr. Des compétences techniques poussées ne sont pas nécessaires, le comité de pilotage doit surtout s'occuper de la partie fonctionnelle.

Concernant le planning :

• Je pense qu'il serait bien que le comité de pilotage se réunisse (en visio) en décembre pour commencer à travailler.
• Le conseil d'administration votera normalement le budget en janvier.
• L'objectif est de lancer l'appel d'offres en février.

Cordialement, --Mathis B ^discuter, le 20 novembre 2022 à 11:47 (CET)

Hello @Mathis B. Voilà d'excellentes nouvelles ! Merci à tous  ; je suis ravi que le projet soit en bonne voie. Je suis partant pour le comité de pilotage ; ce serait bien qu'au moins un autre wikipédien/patrouilleur qui a participé à l'élaboration du cahier des charges en fasse partie. — Jules* ^discuter 20 novembre 2022 à 13:38 (CET)

Je suis du même avis, un autre patrouilleur serait une bonne chose.  Jules* : peux-tu m'envoyer un courriel s'il-te-plait, que je retrouve plus facilement ton adresse. --Mathis B ^discuter, le 21 novembre 2022 à 18:19 (CET)

Bonjour, je relance le sujet puisqu'aucun autre patrouilleur ne s'est proposé. Cordialement, --Mathis B ^discuter, le 25 novembre 2022 à 14:45 (CET)

Ping @Hyméros, @RG067, @LucienB49, @User92259453, @Mathis B, @Culex, @Golmote, @Martin-78, @LD et @Ryse93, @Thibaut120094, @Qwerty1999, @Od1n, @Gratus, @Aymeric50800, @JackJackpot, @Pa2chant.bis et @Locpac. — Jules* ^discuter 25 novembre 2022 à 15:37 (CET)

Bonjour! Merci pour tout ce travail et la notif'. Si besoin je peux donner un coup de main au comité de pilotage, cependant niveau temps (planning + décalage horaire) et connexion internet, il me sera assez compliqué de participer à des réunions en visio suite à mon expatriation.--Martin-78 ^{(discutailler)} 25 novembre 2022 à 15:43 (CET)

S"il faut participer à une visio pour donner mon avis en tant que patrouilleur ou admin, pas de problème. Par contre, je n'ai aucune compétence du point de vue technique. Culex (discuter) 25 novembre 2022 à 16:08 (CET)

 Martin-78 et Culex : (et les autres) pour être plus précis, le but du comité va être de "piloter" la phase de développement. Concrètement, il faut affiner le cahier des charges, superviser l'appel d'offres (rédaction, critères pour départager, sélection du prestataire) et suivre le développement en supervisant les tests avec la communauté. On est beaucoup sur l'aspect technique pour le moment (Jules un peu moins mais il a de bonnes notions quand même), donc d'autres regards sont les bienvenus. Pour les quelques aspects techniques qui seraient éventuellement nécessaires, on se chargera de les vulgariser . Cordialement, --Mathis B ^discuter, le 25 novembre 2022 à 16:28 (CET)

Hello @Mathis B,

Et bien pas de soucis pour ma part, je n'ai pas de compétence au point de vue technique non plus, mais pas de soucis pour aider comme je peux ! Martin-78 ^{(discutailler)} 25 novembre 2022 à 17:43 (CET)

Parfait, alors. Je vous fais signe si je peux m'engager sur la durée à assurer le back up. --Pa2chant.bis (discuter) 25 novembre 2022 à 20:26 (CET)

Si on est trois (Martin-78 et/ou Culex et/ou Pa2chant.bis et moi), ce n'est pas plus mal. Même si de toute manière on tiendra systématiquement l'ensemble du projet informé. — Jules* ^discuter 26 novembre 2022 à 00:00 (CET)

Salut ! Merci pour le ping. Je suivrai le projet avec attention, mais faire partie du comité de pilotage dépasse le niveau d'investissement que je souhaite y accorder. --Golmote (discuter) 25 novembre 2022 à 23:31 (CET)

Pas de problème pour moi, dans la limite de mes compétences bien sûr. Culex (discuter) 26 novembre 2022 à 00:02 (CET)

 Martin-78 : si ta connexion internet et ton temps sont un obstacle, peut-être vaudrait-il mieux que  Pa2chant.bis ou  Culex en fasse partie. Cordialement, --Mathis B ^discuter, le 26 novembre 2022 à 09:24 (CET)

Pas de problème @Mathis B, et si un jour vous avez besoin d'un coup de pouce je reste joignable sans soucis. Martin-78 ^{(discutailler)} 26 novembre 2022 à 09:39 (CET)

 Pa2chant.bis et Culex : je relance, l'un de vous souhaite-il faire partie du comité ? --Mathis B ^discuter, le 27 novembre 2022 à 20:43 (CET)

Oui, ok pour moi, comme dit plus haut. Culex (discuter) 27 novembre 2022 à 22:35 (CET)

Parfait, peux-tu m'envoyer un courriel à mathis.benguiguiwikimedia.fr ? --Mathis B ^discuter, le 27 novembre 2022 à 22:56 (CET)

Hello à tous et merci à @Jules* pour la notif. Désolé pour la réponse tardive, semaine irl un peu chargée.

Je suis également dispo pour le comité de pilotage.

Amicalement, JackJackpot (devisons) 28 novembre 2022 à 01:25 (CET)

Je ne me formaliserai si la candidature de JackJackpot est retenue, je ne n'ai pase encore de visibilité sur mon planning du T1 2023. --Pa2chant.bis (discuter) 28 novembre 2022 à 03:09 (CET)

Bonjour, à titre personnel je pense qu'il serait bon que le comité ne soit pas composé que d'hommes, donc il pourrait être bien que ça soit plutôt  Pa2chant.bis. Cordialement, --Mathis B ^discuter, le 28 novembre 2022 à 10:48 (CET)

Est-ce que c'est gênant si on est trois @Mathis B ? Pa2chantbis + Culex ou JackJackpot + moi ? — Jules* ^discuter 28 novembre 2022 à 12:35 (CET)

Ça ne me parait pas gênant. --Mathis B ^discuter, le 28 novembre 2022 à 13:26 (CET)

Non mais je veux juste aider. Si ma présence implique l'absence de quelqu'un d'autre, pas de souci pour retirer ma candidature. Il y aura beaucoup d'autres occasions pour moi d'apporter ma pierre à l'édifice. JackJackpot (devisons) 28 novembre 2022 à 18:20 (CET)

Puisque j'ai déjà reçu des courriels de  Jules*, Pa2chant.bis et Culex, je pense qu'on peut s'en tenir là si ça convient à tout le monde . Je reviens vers vous dès que le comité est complet, j'espère dans la semaine. --Mathis B ^discuter, le 28 novembre 2022 à 20:28 (CET)

Pour vous tenir tous au courant, la première réunion du comité de pilotage (dont je suggère que nous indiquions la composition sur Wikipédia:Patrouille RC/Projet LiveRC 2.0, @Mathis B) se tient demain soir ; nous vous ferons un compte-rendu . — Jules* ^discuter 15 décembre 2022 à 12:37 (CET)

J'ai initialisé la page Wikipédia:Patrouille RC/Projet LiveRC 2.0/Développement, à compléter. --Mathis B ^discuter, le 15 décembre 2022 à 13:02 (CET)

Compte-rendu de la première réunion de pilotage

Bonjour,

Pour rappel, la composition du comité de pilotage est accessible ici : Wikipédia:Patrouille RC/Projet LiveRC 2.0/Développement.

Voici un compte-rendu de la réunion du 15 décembre, qui a duré près de deux heures ; nous étions tous présents sauf Jitrixis qui a eu un empêchement de dernière minute. Toute la première partie a servi à ce que tout le monde soit au même niveau d'information. Tout au long de la réunion, Envel Le Hir, Kelam et Mathis B ont apporté un éclairage sur les aspects techniques et sur les habitudes en matière d'appel d'offres pour développement de logiciel.

• Calendrier : le CA de WMFr examinera le sujet en février pour débloquer un budget pour le développement. Le budget nécessaire estimé pour le développement du logiciel a été établi par plusieurs membres de WMFr avec des compétences en développement (cf. section ci-dessus). L'appel d'offre devrait être publié en février 2023. D'ici-là, une nouvelle réunion du comité de pilotage est prévue en janvier pour peaufiner certains points restés en suspens à l'issue de la réunion.
• Budget : plusieurs points relatifs au budget prévisionnel ont été discutés. Entre autres, il a été précisé que le budget comprenait un temps de tests (pour les allers-retours avec la communauté après chaque livrable intermédiaire), ainsi qu'un temps de correction des bugs, à l'issue du développement.
• Questions techniques : plusieurs aspects techniques ont été évoqués. Il a été clarifié que la réutilisation possible du code de LiveRC n'était pas souhaitable ni envisagée ; la réutilisation d'une partie du code de SWViewer, comme base de LiveRC 2.0, pourrait être ou ne pas être (incertitude) pertinente techniquement et financièrement, si seulement elle est possible (licence).
• Découpage en lots du cahier des charges : un découpage en lots du cahier des charges a été ébauché, mais ne sera pas rendu public, de sorte à pouvoir juger le découpage que proposeront les répondants à l'appel d'offres. Pour mémoire, le découpage en lots conditionnera les livrables intermédiaires, qui seront des occasions pour la communauté de tester le logiciel au fur et à mesure, de sorte à vérifier qu'il correspond bien à ce qui est souhaité (par exemple, un premier livrable pourrait ne contenir que les fonctionnalités les plus basiques et le design envisagé pour l'outil).
• Détermination des critères de choix du prestataire : nous avons discuté les différents critères pour choisir le prestataire et surtout leur poids respectif (en pourcentage), en fonction de leur importance estimée. Ledit poids n'a pas été arrêté, mais les différents critères évoqués sont, pour information : les coûts ; le délai de livraison proposé par le prestataire ; le support sous garantie proposé à l'issue du développement (correction de bugs) ; l'ergonomie du logiciel (facilité d'utilisation, LiveRC faisant figure de contre-exemple ; nous avons insisté sur l'importance de ce point) ; la pertinence de la solution technique proposée (incluant l'architecture logicielle, les technologies proposées et la facilité ultérieure de prise en main par la communauté bénévole pour la maintenance du logiciel, le découpage en lots, la documentation technique) ; la documentation fonctionnelle. Points bonus évoqués : connaissance préalable de Mediawiki et de son API ; compréhension du fonctionnement de Wikipédia. Plusieurs pré-requis ont en outre été listés : code sous licence libre ; utilisation de l'outil Git de la WMF ; respect du cahier des charges.
• Ajouts dans le cahier des charges : ont été ajoutés la personnalisation des couleurs du logiciel (accessibilité, notamment pour personnes malvoyantes et daltoniennes) ; la publication du code sous licence libre (cf. ci-dessus).
• Prochaines étapes :
  • rédaction, asynchrone et via un document partagé, d'un cahier des charges plus détaillé (discussions nécessaire pour déterminer exactement la forme qu'il doit prendre), plus approprié à l'appel d'offres ;
  • réunion (ne nécessitant pas la présence de la totalité du comité de pilotage) avec des salariés de WMFr qui ont davantage d'expérience en matière d'appels d'offres ;
  • réunion du comité de pilotage en janvier, après validation des deux points ci-dessus, pour valider le contenu de l'appel d'offres.

Cordialement, — Jules* ^discuter 21 décembre 2022 à 14:23 (CET)

Petit point sur l'avancement du projet

Hello !

J'étais absent lors de la seconde réunion du comité de pilotage, le 21 janvier, mais la prise de notes par les personnes présentes me permet de vous en faire un court compte-rendu, de même qu'un point sur l'avancement du projet.

• Composition du COPIL. Déjà, pour info, Pa2chant.bis s'est retirée du comité de pilotage (je la laisse préciser si elle le souhaite, mais ça n'est pas lié au présent projet) ; JackJackpot, qui s'était précédemment proposé, la remplace. Pour mémoire, la composition du COPIL est indiquée sur Wikipédia:Patrouille RC/Projet LiveRC 2.0/Développement.
• Compte-rendu de la réunion du 21 janvier :
  • L'étude du code de SWViever par Mathis B a permis de conclure qu'il n'était pas envisageable d'utiliser cet outil de patrouille comme base logicielle pour LiveRC 2.0
  • Il a surtout été question de la finalisation de la rédaction de deux documents : le cahier des charges et l'appel d'offres. Sur ce dernier point, une réunion avec une partie du COPIL et des salariés de Wikimédia France habitués à la rédaction d'appels d'offres s'est tenue quelques jours auparavant. Concernant les deux documents, il restait — et reste encore — en effet des éléments à rédiger (en plus d'une mise en page dans un document classique des éléments jusque-là rédigés sur Wikipédia), notamment pour clarifier le contexte du projet, les attendus, détailler le fonctionnement actuel de LiveRC (avec illustration par des captures d'écran), etc. Tout cela de sorte que les candidats à l'appel d'offres aient tous les éléments en main avant de proposer leur prestation.
  • Le cahier des charges — dont la liste des fonctionnalités demandées, que nous avions réalisée collectivement, n'a pas été modifiée ; seuls des éléments de contexte et des précisions techniques sont apportés — une fois finalisé, sera repartagé ici pour relecture et validation collective.
• Prochaines étapes :
  • Le conseil d'administration (CA) de Wikimédia France se réunissait il y a deux jours, samedi 4 février, et devait à cette occasion attribuer formellement le budget dédié à l'outil et valider la composition du comité de pilotage. Nous devrions rapidement avoir des nouvelles du CA, normalement avec validation de l'ensemble .
  • Il restera à finaliser le cahier des charges et l'appel d'offres (il y a encore un peu de boulot).
  • Les deux conditions ci-dessus réunies, l'appel d'offres pourra être publié.

— Jules* ^discuter 6 février 2023 à 15:47 (CET)

Courte réunion impromptue en vocal ce soir à 21 heures

Bonjour,

Le conseil d'administration de Wikimédia France souhaite nous faire un retour en visio-conférence ce soir à 21 heures.

Pour info, il nous a été annoncé par courriel que si le budget était validé, le CA n'avait pas souhaité valider les autres points (non nommés, mais a priori : composition du comité de pilotage, contenu du cahier des charges…), pour des raisons « stratégiques » (non précisées) et car il lui était apparu qu'il y avait une opportunité d'améliorer l'accueil des nouveaux pour éviter que LiveRC ne soit un outil de patrouille qui incite trop à des comportements trop rugueux à l'égard de ces derniers. C'est en tout cas ce que j'en retiens, grosso modo ; j'aurais bien aimé que ce soit le CA qui vienne l'annoncer ici (mais c'est visiblement le but de la réunion en vocal).

J'ai indiqué, par retour de courriel, ma surprise — pour dire le moins — quant au fait que les remarques relatives à l'accueil des nouveaux, si elles me semblaient recevables dans une certaine mesure, étaient tardives et que je ne saisissais pas leur articulation avec la non-validation du COPIL. J'ai également posé la question de la gouvernance du projet.

Le vocal de ce soir a été proposé par le CA pour apporter des précisions. Vous pouvez même venir sans micro, juste pour écouter, si vous le désirez.

Pour l'URL de connexion à la visio-conférence : envoyez-moi un courriel.

— Jules* ^discuter 9 février 2023 à 16:46 (CET)

Bonsoir @Jules*.

Ils ont envoyé l'invitation à tout le monde ? J'ai vérifié mes mails et n'ai pas l'impression d'avoir reçu d'invitation. JackJackpot (devisons) 9 février 2023 à 22:10 (CET)

 JackJackpot : Bonjour, l'info avait été envoyée sur la liste du comité de pilotage par Envel, tu as donc dû l'avoir. --Mathis B ^discuter, le 9 février 2023 à 22:15 (CET)

Hello @JackJackpot. C'est un mail d'Envel envoyé mardi 7 à la liste du COPIL ! La discussion a duré trois-quarts d'heure, mais le CA va de WMFr va de toute manière tout remettre par écrit ici, donc tu n'auras pas raté grand chose.

J'ai insisté pour qu'à l'avenir, on favorise les discussions publiques ici (sauf pour les détails techniques ou aspects confidentiels type budget de l'appel d'offre, qui ont vocation à être discutés sur la liste de courriel du COPIL) afin de permettre l'information et l'implication de tout le monde . — Jules* ^discuter 9 février 2023 à 22:15 (CET)

Conflit d’édition — Correction : je vois que tu n'es pas dessus, l'interface des listes a dû avoir un bug, toutes mes excuses… --Mathis B ^discuter, le 9 février 2023 à 22:16 (CET)

Normalement ça a fonctionné cette fois, dis moi si tu as bien reçu le mail d'inscription. --Mathis B ^discuter, le 9 février 2023 à 22:19 (CET)

@Mathis B Bien reçu cette fois, merci !

Bonne soirée, JackJackpot (devisons) 9 février 2023 à 22:28 (CET)

Lancement de la phase de mécénat et quelques questions de gouvernance

Bonjour,

Comme indiqué par @Jules*, je fais un petit message ici pour le CA de Wikimédia France (et je laisse @Envel Le Hir, @Hatonjan et @Lepticed7, qui étaient là hier, compléter si besoin). Nous avons fait une réunion hier mais sans prendre de décision, le lieu pour cela étant pour l'instant la présente PDD (et la liste de discussion du COPIL pour les choses confidentielles concernant l'appel d'offres qui sera mené). Personnellement, je maintiens que les réunions en direct sont parfois utiles pour présenter les idées et les éclaircir directement .

Ce week-end, le CA de Wikimédia France a inscrit un premier budget pour LiveRC pour l'exercice 2022-2023. Nous voulons à la fois une dépense et une recette, car nous estimons que le projet a un fort potentiel pour le mécénat. La prochaine étape est donc de porter une demande de mécénat, ce qui sera fait par la brillante @Alejandra Reyes WMFr, en collaboration avec le tout aussi brillant @Michael Barbereau WMFr pour la partie technique. Je vais les laisser s'exprimer, mais en gros il va falloir que l'on explique en quoi ce projet est utile pour obtenir les financements ; en parallèle on va pouvoir raffiner la partie technique.

Le CA est très enthousiaste sur le projet, néanmoins nous ne sommes pas encore sûrs de la gestion de projet que nous voulons avoir précisément. À ce titre, j'invite le COPIL à décider s'il veut être un groupe informel, un groupe de travail officiel de l'association, une commission, ou encore exister sous une autre forme. Nous avons également une suggestion, qui est d'agrandir la portée du projet pour y intégrer une recherche en design (ou d'autres disciplines) portant sur :

• comment peut-on intégrer au futur LiveRC des fonctionnalités favorisant l'empathie et l'accueil des nouveaux/nouvelles ?
• comment peut-on rendre l'expérience de patrouille plus positive pour les patrouilleurs/patrouilleuses comme pour les personnes patrouillées ?
• comment évaluer l'impact que peut avoir la patrouille sur la participation à l'encyclopédie ?

Le mécénat pourrait être obtenu afin de permettre les deux actions (développement et recherche), en favorisant le développement si le mécénat n'est pas aussi élevé qu'espéré. N'hésitez pas si vous avez des idées complémentaires (je remercie @Mathis B, @Golmore et en particulier @Waltercolor pour votre présence et vos remarques pertinentes hier soir). Capucine-Marin Dubroca-Voisin (discuter) 10 février 2023 à 16:02 (CET)

Mon avis technique

Bonjour à tous et toutes.

Je découvre ce projet aujourd'hui après ne plus avoir visité WP depuis des mois, et je dois dire que je suis ravi de constater que le projet d'améliorer pour de bon LiveRC semble, pour une fois, en passe de se concrétiser. J'aurai souhaité rencontrer plus d'enthousiasme et de vonlontarisme à l'époque où j'avais tenté de lancer mw:Extension:LiveRC.

Je préfère doucher dès à présent tout espoir que d'aucuns pourraient avoir : je n'ai en aucune façon l'intention de travailler sur ce projet, ni de reprendre la maintenance de LiveRC 1.0, ni même de revenir sur Wikipédia. Je me contente aujourd'hui de donner très ponctuellement mon avis technique.

Des deux solutions techniques proposées, à savoir sous la forme d'un gadget 100% javascript comme l'est actuellement LiveRC 1.0, ou d'un programme hébergé sur un site tiers, me semblent avoir des défauts rédhibitoires.

La forme de gadget permet certes une mise à jour aisée (si l'on sait ce que l'on fait), mais présente les inconvénients de la lourdeur (notamment du fait des très nombreuses requêtes API qui nécessitent une bonne connexion) et de l'impossibilité d'une patrouille "collaborative" en raison du caractère "client" du language utilisé.

L'hébergement sur un site tiers pourrait permettre une patrouille collaborative (suivant l'architecture logicielle déployée), mais laisse la communauté à la merci des gestionnaires de ce site tiers, et ne règle qu'en partie les problèmes de lourdeur si le logiciel continue de nécessiter d'innombrables requêtes API.

C'est pourquoi, comme à l'époque, je pense que LiveRC 2.0 devrait prendre la forme d'une extension MediaWiki, pour les raisons déjà évoquées sur mw:Extension:LiveRC :

• LiveRC serait pleinement intégré à MediaWiki, sous la forme d'une page spéciale, y compris éventuellement les fonctions de configuration (/site) et de customisation (/user).
• L'accès à certaines infos impossibles à avoir autrement serait disponibles, par exemple l'accès à la configuration exacte de l'extension Flow ou FlaggedRevs (quoique j'ai crû comprendre que Flow était abandonné ?).
• La récupération d'infos telle que la liste des sysops et bots, des utilisateurs récemment bloqués, etc, se ferait via des requêtes SQL directement dans la base de données, donc bien plus rapidement qu'avec des requêtes API, et ne courrait pas le risque d'être oblsolète comme ce serait le cas avec une liste sauvegardée en dur.
• Les accès, tant à LiveRC lui-même qu'à ses différentes fonctions, pourrait être géré via des droits utilisateurs impossible à court-circuiter, droits qui pourraient être accordés/retirés par les bureaucrates locaux (il faudrait pour cela définir des groupes d'utilisateurs ayant tels ou tels droits liés à LiveRC).
• Une partie Javascript subsistera nécessairement pour la mise à jour des RC (qui se fait côté client), laquelle pourrait être effectuée par un seul module API dédié à LiveRC regroupant toutes les infos nécessaires (plus besoin d'1 requête pour les RC, puis 1 requête par ligne pour les infos de l'utilisateur modificateur + 1 requête par ligne pour les infos sur la page modifiée, une seule requête regrouperait tout ça pour un gain de performance conséquent, et encore je ne parle même pas d'une éventuelle utilisation cross-wiki, qui multiplie le besoin de requêtes).
• La partie javascript pourrait conserver un système de "hooks" tel que celui déjà en place actuellement pour permettre l'utilisation d'extensions (typiquement, l'item du cahier des charges concernant les icônes à ajouter pour les utilisateurs révoqués par Salebot ou ceux ayant fait l'objet d'un avertissement (test 1, etc...) devrait être géré comme cela, car il est bien trop dépendant du site où LiveRC opère pour être intégré dans un outil qui se veut global).
• Si une telle extension était créée et s'avérait plébiscitée (installée sur de nombreux wikis de la foundation), elle se retrouverait sur les radars des développeurs de mediawiki, avec les avantages qui vont avec : ils pourraient prendre en charge la maintenance de l'extension, voire son développement futur, ils seraient attentifs aux éventuels besoins spécifiques de l'extension lors de futures mise à jours de mediawiki, etc... Et peut-être une jour l'extension serait-elle dirctement intégrée à mediawiki, comme l'ont été les parsers functions par exemple.

Bref, si je devais choisir une voie pour "refaire" LiveRC, c'est celle d'une extension MediaWiki que je prendrais.

Quelle que soit la solution technique retenue, bon courage à ceux qui s'y colleront.

88.137.136.100 (discuter) 10 mars 2023 à 00:19 (CET)

Bonjour,

Content de te voir passer et donner quelques nouvelles, même très ponctuellement, et cet avis technique. Il arrive en plus au bon moment, alors que nous sommes encore dans la phase de préparation de l'appel d'offres.

En ce qui me concerne, je suis totalement convaincu par l'argumentaire (même si les WMF Labs ne sont pas vraiment un « site tiers », puisque c'est mis à disposition par la fondation). Et même s'il nécessite quelques changements dans le cahier des charges, c'est à mon avis pour le mieux.

D'autres avis ? Je notifie les membres du comité de pilotage :  Jules*, JackJackpot, Culex, Waltercolor, Like tears in rain, Envel Le Hir, Envlh, Julien Gardet, Jitrixis, Jean-Baptiste Laurent et Kelam.

Cordialement, --Mathis B ^discuter, le 10 mars 2023 à 09:17 (CET)

PS : pour ceux qui n'auraient pas compris, le message ci-dessus a été posté par Dr Brains (d · c · b). --Mathis B ^discuter, le 10 mars 2023 à 09:42 (CET)

Bonjour Dr Brains (j'avoue avoir été surpris de l'intervention d'une IP sur cette page, avant de comprendre aussi à la lecture)

Je suis moi aussi entièrement d'accord avec cette analyse et j'avoue n'avoir jamais envisagé qu'il en soit autrement.

Jean-Baptiste Laurent (discuter) 10 mars 2023 à 10:57 (CET)

Salutations et remerciements, Dr Brains. Sur le plan technique, je ne maîtrise pas le sujet. @0x010C ? — Jules* ^discuter 10 mars 2023 à 13:36 (CET)

Bonjour,

Effectivement dans un monde idéal c'est incontestablement la meilleur solution. Excepté le dernier point, j'abonde quant aux avantages présentés. Cependant, je tiens à apporter un peu de contexte.

Je passe outre le niveau de connaissances dans MediaWiki bien plus élevé à avoir et la complexité que cela ajoutera dû à la descente d'un niveau d'abstraction. Il ne faut surtout pas oublier que le code devra respecter une série de critères bien plus exigeants que sur Toolforge pour pouvoir être déployer sur Wikipédia, et qu'il faudra passer par une longue procédure d'examen et de validation, décrite sur cette page : Writing an extension for deployment. Pour faire un résumé très résumé de cette page, il faut un consensus sur le wiki, tester la compatibilité avec toutes les extensions déjà déployés sur les wikis, assurer que l'extension sera maintenu dans le temps, passer la product-owner review, la design review, la security readiness review, la security review pour toutes les dépendances, la performance review et éventuellement la database review, déployer et tester sur le beta-cluster avant de peut-être arriver sur frwiki.

Cela implique plusieurs points :

1. Le risque d’échec : Chaque évaluateur peut bloquer complètement le déploiement de l'extension, avec le risque de tomber sur un point de blocage insolvable ;
2. La maintenance : WMFr doit s'engager, en plus du développement initial, à maintenir l'extension sur le long terme ;
3. Le coût : Plus de développement, plus de gestion de projet, plus d'exigences en terme de performances, de sécurité, et sans oublier les maintenances ponctuelles à long terme ; cela coûtera forcément plus chère.

Et j'en reviens à mon introduction : idéalement c'est clairement et de loin la meilleur solution pour tous les arguments apportés plus haut, mais c'est aussi à mes yeux la plus risquée et la plus coûteuse.

Bon courage à tous — 0x010C ^~discuter~ 10 mars 2023 à 16:38 (CET)

Merci  0x010C pour ces éléments, et en l'occurrence la chaine de reviews nécessaire me semble bloquante : elle empêche de faire des livraisons intermédiaires et des tests. --Mathis B ^discuter, le 10 mars 2023 à 17:33 (CET)

Pas vraiment. Des livraisons intermédiaires peuvent être réalisés sur un wiki de test (voir sur le beta-cluster), mais c'est sur on n'aura pas la même quantité de diffs/secondes dessus pour analyser les performances. De mon point de vue ce qui va surtout être bloquant pour cette option c'est le budget que WMFr est prêt ou non à mettre dans le projet. — 0x010C ^~discuter~ 11 mars 2023 à 16:34 (CET)

J'avoue ne pas maitriser très bien le sujet, mais je ne suis pas sûr que ce soit le rôle des membres du comité de pilotage de se prononcer. Ces derniers et dernières me semblent plus compétents pour se prononcer concernant l'aspect fonctionnel du nouvel outil. Si la question des performances est déterminante, c'est davantage l'hébergeur qu'il faut impliquer. JackJackpot (devisons) 13 mars 2023 à 00:36 (CET)

Point d'étape et gestion de projet

Bonjour à toutes et tous,

Afin de relancer le travail sur ce projet important et peut-être lever les quelques zones d'ombres subsistantes concernant le budget et la gestion de projet, je souhaiterais avoir un bref échange avec toutes les personnes qui le souhaitent dans les 15 prochains jours. Ce sera l'occasion de se reconnecter et d'exprimer nos attentes respectives. J'ai bien conscience que nous/je n'ai pas été très réactif sur ce sujet dernièrement et j'en suis sincèrement désolé. Bref, je me tiens à votre disposition. Cela peut se faire en soirée ou en week-end selon votre convenance.

J'espère à très vite :)

Merci, Rémy Gerbet WMFr (discuter) 12 avril 2023 à 16:04 (CEST)

Quinze jours ont passé, et nous ne sommes que 2 à avoir répondu par mail.

Je me permets donc de pinger les inscrits qui n'ont pas signalé leur prise de recul :  RG067, LucienB49, User92259453, Culex, Golmote, Martin-78, 0x010C, LD, Ryse93, Thibaut120094 et Qwerty1999 :  Od1n, Juste Juju, Loïs WAHL, Gratus, JackJackpot, Arkanosis, Locpac, Lepticed7, Anto Napo le bô et Manjiro5 :

Jean-Baptiste Laurent (discuter) 26 avril 2023 à 16:14 (CEST)

Bonjour @Jean-Baptiste Laurent @Rémy Gerbet WMFr, je suis disponible pour répondre, mais je n'ai pas reçu de mail manȷıro^💬 26 avril 2023 à 16:35 (CEST)

Bonjour @Rémy Gerbet WMFr@Jean-Baptiste Laurent

Je viens de vérifier dans ma boîte, et il semble que je n'ai pas non plus reçu de mail... JackJackpot (devisons) 29 avril 2023 à 22:48 (CEST)

Toutes nos excuses, il y a eu effectivement un doublon de discussion entre mails et Wiki. On va recentrer toutes les discussions ici pour plus de transparence et de praticité. Je remets donc ici les éléments importants que j'avais communiqué par mail. Du côté de l'association et notamment de l'équipe salariée voilà ce que l'on a fait depuis le vote du budget.L'objectif premier était de trouver :

• Le financement nécessaire pour engager les travaux que ce soit par un appel d'offres ou un développement en interne.
• S'assurer que le projet soit viable sur le long terme et donc que cela ne s'arrête pas après une simple prestation et penser à la question de l'hébergement et de la maintenance.

Nous avons donc, avec ma collègue Alejandra Reyes WMFr, et en s'appuyant évidemment sur tous les éléments présents sur Wikipedia constitué un dossier de recherche de financement afin d'aller démarcher de potentiels mécènes. Nous avons aussi envisager la possibilité d'un mécénat de compétences en tech ce qui permettrait d'avoir une personne dédiée au développement sur un temps plus long qu'une prestation.

Après avoir sollicité l'aide d'Open Food Fact qui a plus d'habitude que nous sur de ce type de mécénat, j'ai déposé un dossier à Share It concernant Live RC. Nous devrions avoir une réponse très prochainement.

En attendant, nous avons aussi envisager le fonds technologique de la WMF. Ce serait assez pertinent au vu du projet de faire de Live RC un outil pas seulement utile pour la WP Fr mais potentiellement d'autres projets Wiki aussi. Et même si cela reste limité à la WP francophone cela demeurerait pertinent. Je ne me suis pas encore plongé dans cette option et en plus, il semblerait que ce système de grant ne soit pas encore au point à la WMF :

Concernant les questions autour du design de l'outil,nous n'avons pas encore avancé sur ce sujet car je ne l'avais pas vraiment en tête et je pense qu'une discussion collective nous permettrait de redéfinir les attentes. Cependant, j'avais en tête d'intégrer dans le groupe de travail peut-être au moment de la phase de cadrage du développement, une réunion spéciale sur ce sujet. On pourrait inviter quelques scientifiques et chercheurs qui ont travaillé sur ces questions voir des personnes de la WMF spécialisées sur ces sujets d'accueil des nouveaux et peut-être inclure dans le budget un designer en plus du développeur.

Voilà les éléments en ma possession. Je serais évidemment ravi d'échanger avec vous sur ce sujet dans les prochains jours en fonction des disponibilités de chacun. Je peux vous proposer un framadate afin de définir une date de visio sur ce sujet :

Lien vers le formulaire de date

Merci à toutes et tous, Rémy Gerbet WMFr (discuter) 27 avril 2023 à 10:28 (CEST)

J'ai répondu au Framadate. — Jules* ^discuter 27 avril 2023 à 14:58 (CEST)

Bonjour à toutes et tous,

merci à celles et ceux qui ont déjà rempli le sondage. N'hésitez pas à renseigner vos disponibilités :D Rémy Gerbet WMFr (discuter) 2 mai 2023 à 09:51 (CEST)

Bonjour à toutes et tous, je vous annonce donc que l'on fera une réunion de mise à jour sur le projet Live RC 2.0 le 17 mai à 20h00. Je mettrais le lien de visio sur cette page. Merci Rémy Gerbet WMFr (discuter) 10 mai 2023 à 11:47 (CEST)

Bonjour. actuellement j'ai laissé wikipédia pour le bac. je vous laisse gérer j'ai confiance en vous. Loïs Wahl(laisse moi un message) 15 mai 2023 à 10:56 (CEST)

Bonjour à toutes et tous,

Voici le lien pour la réunion de ce soir à 20h00. À ce soir, Rémy Gerbet WMFr (discuter) 17 mai 2023 à 14:00 (CEST)

Notes techniques

Bonjour, après l'annonce de la volonté de créer un "LiveRC 2.0", j'avais commencé à développer localement un "LiveRC minimaliste", surtout pour voir l'allure qu'aurait une base minimale, se voyant ensuite ajouter progressivement les fonctionnalités. Ça date d'il y a déjà plus d'un an ! C'est un développement que j'avais finalement "rage quit" assez rapidement, explications à la fin de ce message, mais j'en ai quand même tiré quelques observations qui peuvent s'avérer utiles.

• J'ai utilisé les EventStreams. Au début ça avait l'air sympa, mais une fonctionnalité de base n'était pas possible : récupérer les RC s'étant produits avant le lancement du script (pour ne pas avoir une fenêtre vide au lancement du script, mais avoir déjà une poignées de RC passés).
  • Les RC passés sont présents dans le stream, le problème se situe au niveau de l'implémentation EventSource des navigateurs qui ne permet pas de récupérer les éléments passés d'un stream. On serait donc obligé de ne pas utiliser l'implémentation EventSource des navigateurs, mais une librairie tierce implémentant EventSource, le genre de librairie n'étant vraiment pas de toute légèreté.
  • J'avais essayé la librairie wikimedia-streams, mais du peu que j'avais regardé le code était à la ramasse. Je ne me souviens plus si cette librairie permet de récupérer les RC passés.
  • Par conséquent, je pense que le mieux serait de s'en tenir aux bonnes vieilles requêtes API. De toute façon, considérant les performances des serveurs Wikimedia, ainsi que des ordinateurs et navigateurs actuels, et les bandes passantes de folie que nous avons maintenant, avec les requêtes API on peut avoir quelque chose de très performant. J'utilise régulièrement l'API JavaScript pour analyser des milliers de pages/edits, et ça passe crème.
• J'avais réussi à avoir une interface redimensionnable vraiment sympa, avec nommément la librairie Split.js (sur GitHub). Ça a l'air de fonctionner parfaitement, et la librairie est très légère.
  • Avec en fallback si la librairie n'est pas chargée, une interface aussi redimensionnable, mais de façon moins ergonomique.
  • C'est l'un des défauts que je trouve au LiveRC actuel : le code pour l'interface redimensionnable est très lourd (notamment à cause de callbacks qui tournent en continu en arrière-plan). On ne s'en rend pas compte sur Chrome, mais sur un navigateur moins optimisé on le ressent clairement. J'avais un peu optimisé ce code et ça tourne un peu mieux, mais sur ledit navigateur non optimisé ce n'est pas encore vraiment fluide.
• Même sur cette maquette minimaliste, je suis rapidement tombé sur les mêmes problèmes d'affichage des prévisualisations que sur le LiveRC actuel. Voir Discussion MediaWiki:Gadget-LiveRC.js#Gestion des styles dans les prévisualisations. D'ailleurs c'est encore en bazar sur le LiveRC actuel. Pour résumer, c'est un enfer (là vous pouvez me croire) d'héritages de CSS, et codés en dur bien comme il faut, tout est entremêlé et quand on corrige un truc, on en casse deux autres ailleurs…

Ce sont ces problèmes d'affichage des prévisualisations en particulier, qui m'ont fait "rage quit" le développement de cette maquette. Et aussi le fait que même pour une maquette minimaliste, le code devient vite complexe.

Au final j'ai quand même eu une maquette fonctionnelle, qui récupère les RC, affiche ceux-ci et leurs aperçus franchement perfectibles (cf. supra), de visualiser les contributions de l'utilisateur, cela dans une interface redimensionnable bien sympa. Mais quand les boîtes de Pandore et prises de tête ont commencé à apparaître, je me suis rendu compte que cela m'aurait pris un temps considérable de continuer ce développement, pour un projet dont je voulais simplement produire une maquette et que je n'aurais même pas utilisé…

od†n ↗^blah 27 avril 2023 à 03:17 (CEST)

Salut @Od1n. Merci pour ton retour d'expérience. Juste une remarque/question concernant les difficultés de prévisualisation : y a-t-il quelque chose qui empêcherait d'utiliser des iframes dynamiques ? Cela devrait éliminer les problèmes d'héritage de styles imprévus. --Golmote (discuter) 17 mai 2023 à 20:56 (CEST)

Je ne me souviens plus si j'ai déjà fait des tests avec des iframes. La technique serait a priori de charger la page entière dans l'iframe, puis de remplacer tout son contenu par uniquement l'élément #mw-content-text. En faisant ainsi, on a une page bien isolée, avec son propre CSS ; on a la page entière (i.e. avec toute l'interface autour), mais comme j'ai indiqué juste avant, l'interface autour on peut l'enlever. Mais il y a un énorme problème : on charge (et exécute) aussi tout le JavaScript…

Et je viens d'essayer, déjà qu'en remplaçant tout le contenu par l'élément #mw-content-text, on a des problèmes de font size, qui sont fortement similaires aux problèmes déjà rencontrés sur le LiveRC actuel et sur ma sandbox perso (j'ai même l'impression qu'il y a exactement les mêmes problèmes).

Vous pouvez constater par vous-même (attention, sur une page bien à part parce que ça enlève toute son interface autour) :

(() => { let $content = $('#mw-content-text'); $('body').empty().append($content); })();

De mémoire, c'est parce que cela nécessite d'hériter les sizes des éléments parents… qui contiennent aussi des éléments d'interface. En l'occurrence ça serait le "font-size:0.813em" du .vector-body. Puis ça ne suffit pas, parce que l'interlignage n'est encore pas bon, je sais plus pourquoi. Donc on ajoute des rustines, puis ça varie selon la skin utilisée, puis ça varie si on utilise du CSS perso ou un gadget pour défaire la nouvelle typographie de m— de Vector, etc etc. À cela vous pouvez ajouter que le LiveRC actuel applique une réduction de font-size à l'ensemble de son interface, qui se retrouve aussi appliquée aux prévisualisations (j'avais à un moment pensé à séparer en deux préférences : une réduction de font-size pour l'interface, et une autre pour les prévisualisations), et vous pouvez encore ajouter que MediaWiki applique sur les diffs (qui sont en font monospaced) un font-size de 13px. Bref vous l'aurez compris, il y a un de ces bordels avec le CSS…

od†n ↗^blah 18 mai 2023 à 10:11 (CEST)

Oh ok, je comprends mieux, le problème ne vient pas de l'héritage des styles de LiveRC mais simplement du fait que l'apparence du contenu de la prévisualisation dépend de l'héritage des styles de la partie de la page qu'on supprime ! Je n'avais pas pensé à ça, effectivement... --Golmote (discuter) 18 mai 2023 à 19:21 (CEST)

Point Juin 2023

 Jules*, JackJackpot, Culex, Waltercolor, Like tears in rain, Envel Le Hir et Julien Gardet Bonjour tout le monde,

Je vous apporte une bonne nouvelle pour le projet : comme il l'avait annoncé en mai lors d'une visio,  Rémy Gerbet WMFr : est en pleine recherche d'entreprises prêtes à nous proposer un mécénat de compétences pour le développement de LiveRC 2.0. Afin que tout soit prêt une fois les candidatures rassemblées, ce qui devrait arriver au mieux d'ici la fin du mois de juin, je pense qu'il serait bon de finaliser le cahier des charges et l'appel d'offres. La rédaction des documents est en sommeil depuis février sur le cloud. Du coup, est-ce que celleux qui y ont accès peuvent y jeter un œil et dire ce qu'il reste à faire (ajout de paragraphes, notes techniques, copies d'écran) ? On ne fixe pas encore de date, car l'été arrive et forcément, tout va tourner au ralenti, mais il me semble judicieux de se remotiver dès maintenant pour être réactif dès qu'on aura des propositions plus concrètes.

Bonne journée, Jean-Baptiste Laurent (discuter) 7 juin 2023 à 12:04 (CEST)

Bonjour @Jean-Baptiste Laurent et merci de relancer un peu tout ça. La notification n'a pas fonctionné pour moi, donc sans doute pas non plus pour les autres. @JackJackpot, @Culex, @Waltercolor, @Like tears in rain, @Envel Le Hir et @Julien Gardet. — Jules* ^discuter 14 juin 2023 à 11:48 (CEST)

J'ai refait la mise en page des deux documents sur le Cloud. Dites-moi si c'est ok pour vous.

• J'ai ajouté des tables des matières (à mettre à jour quand vous faites des modifs).
• Le doc de l'appel d'offres est à peu près complet mais celui du Cahier des charges est quasi vide.
• Concernant les specs existantes, je les ai listées au début de ce document (j'ai résumé et mis en forme sans les images la description qui figure dans l'appel d'offre).
• Pour chaque fonctionnalité existante, on pourrait déjà apposer les mentions "keep", "change" (préciser quel changement), "suppr".
• Il faudrait ensuite lister en-dessous toutes les nouvelles fonctionnalités à rajouter.

Waltercolor (discuter) 15 juin 2023 à 01:19 (CEST)

@Waltercolor Merci de cet effort de relecture. L'appel d'offres n'est pas forcément la priorité puisqu'on a déjà démarché des entreprises, donc il faut se concentrer sur le CDCF. Tu mets d'ailleurs le doigt sur un point central : en relisant les documents, j'ai l'impression qu'après tout ce temps, les nouvelles fonctionnalités à implémenter pour la patrouille restent mal définies, et pour ce qui est des fonctionnalités à envisager pour l'accueil des nouveaux, n'en parlons pas. Je vais reprendre les échanges passés pour essayer de ressortir ce qui avait été décidé. Jean-Baptiste Laurent (discuter) 15 juin 2023 à 09:28 (CEST)

Bonjour à tous (et notamment @Jean-Baptiste Laurent). Je suis toujours intéressé et intégré au projet mais dans une phase de disponibilité un peu compliquée (cf. mon peu de contributions actuellement). J'ai eu un échange e-mail pour signaler ma disponibilité à Rémy pour rencontrer des entreprises pour le mécénat de compétences (la date clé d'examen de notre dossier étant début juillet). — Like tears in rain ^{-_-} 30 juin 2023 à 09:47 (CEST)

Désolé pour la réponse tardive, beaucoup de trucs sur la planche. Merci @Waltercolor, @Jean-Baptiste Laurent et @Like tears in rain. Si je comprends bien, le gros morceau qu'il reste à faire, dans le cahier des charges, c'est retranscrire Wikipédia:Patrouille RC/Projet LiveRC 2.0/Cahier des charges dans le tableau « Spécifications fonctionnelles pour la version 2.0 ».

La dernière fois (en début d'année), j'avais butté là-dessus car je ne savais pas trop comment faire : en effet, il avait été dit en vocal que Wikipédia:Patrouille RC/Projet LiveRC 2.0/Cahier des charges n'était pas assez détaillé et ne correspondait pas à des spécifications fonctionnelles, mais comment passer de l'un à l'autre est nébuleux à mes yeux. — Jules* ^discuter 30 juin 2023 à 12:40 (CEST)

Hello @Waltercolor, @Jean-Baptiste Laurent, @Like tears in rain et @JackJackpot. J'ai un peu avancé sur le cahier des charges fonctionnelles ([ https://cloud.wikimedia.fr/s/cEsc28asa9PrS25 lien Cloud]), en complétant la rubrique « Afficher dynamiquement la liste des modifications récentes ». Je ne sais pas dire si les valeurs numériques nécessitent une variable INT ou autre (je n'y connais rien SGBD), donc j'ai mis NUM en attendant. Avant que je ne continue avec les autres rubriques : est-ce que ce que j'ai fait correspond à ce qui est attendu ? Dans le cas contraire, quels détails faut-il donner ou non pour aboutir à un document technique opérationnel pour l'appel d'offres ?

Bien à vous, — Jules* ^discuter 4 septembre 2023 à 16:12 (CEST)

Actualités recherche de financements/mécénats

Bonjour @Jules*@JackJackpot@Waltercolor@Jean-Baptiste Laurent@Like tears in rain@Envel Le Hir@Julien Gardet@Culex et celles et ceux que j'ai pu oublié.

Avec un peu de retard, je viens vous faire un point sur les recherches de financements et de mécénats du côté de WMFr.

Concernant les financements directs, deux pistes prometteuses se dégagent :

1. Une entreprise de l'open source française serait prête à financer le projet. L'accord n'est pas finalisé mais les premiers échanges semblent prometteurs.
2. Candidature auprès d'une fondation néerlandaise qui soutient le développement de l'internet libre et qui a déjà soutenu par le passé Open Food Fact et Framasoft. D'après nos amis, le projet Live RC 2.0 rentrerait parfaitement dans le genre de projet que cette fondation finance. La date limite de soumission est le 1er août 2023.

Concernant le mécénat de compétences :

1. Après un échange par mail avec Share It au cours du mois de juin dans lequel ils expliquaient avoir beaucoup de dossiers à traiter, on devait se recontacter début juillet. Donc j'espère avoir des nouvelles prochainement.
2. Nous avons déposé des offres de mécénats de compétences sur des plateformes dédiées aux entreprises comme Vendredi et Alaya. Pour le moment, nous n'avons pas de réponse.

Voilà un état des lieux rapides. Dès que ça bouge de mon côté et que j'ai des réponses je reviens vers vous très vite.

Merci :)

5 juillet 2023 à 15:11 (CEST) Rémy Gerbet WMFr (discuter) 5 juillet 2023 à 15:11 (CEST)

Bonjour @Jules*@JackJackpot@Waltercolor@Jean-Baptiste Laurent@Like tears in rain@Envel Le Hir@Julien Gardet@Culex,

Dans le cadre de la candidature auprès de la NLnet foundation nous aurions besoin d'aide pour la traduction en EN la section Comparaison des outils existants.

Merci par avance aux volontaires Michael Barbereau WMFr (discuter) 12 juillet 2023 à 17:55 (CEST)

@Michael Barbereau WMFr

Je vais commencer un peu ce soir. Pour éviter les doublons de traduction, vous avez un endroit en particulier où mettre le tableau traduit ?

Amicalement, --JackJackpot (devisons) 12 juillet 2023 à 19:20 (CEST)

Ici

Amicalement, JackJackpot (devisons) 14 juillet 2023 à 02:53 (CEST)

@JackJackpot et autres : Bonjour, j'ai traduit le tableau de comparaison des outils en anglais. N'hésitez pas à contrôler ! --Golmote (discuter) 14 juillet 2023 à 09:40 (CEST)

Merci tout le monde, la candidature part cette semaine. Michael Barbereau WMFr (discuter) 18 juillet 2023 à 17:01 (CEST)

Bonjour à tous, merci pour votre travail ! Nous venons de déposer la candidature. Nous aurons une réponse au mois d'août. Alejandra Reyes WMFr (discuter) 18 juillet 2023 à 17:28 (CEST)

Actualités recherche de financements/mécénats Août 2023

Bonjour @Jules*@JackJackpot@Jean-Baptiste Laurent@Like tears in rain@Envel Le Hir@Julien Gardet@Culex @0x010C et tout le monde :)

Voici quelques nouvelles concernant la recherche de financement et de mécénat pour le projet Live RC 2.0. Comme annoncé au début de l'été, une entreprise de l'open source française, à savoir Worteks, a accepté de financer une partie du projet à hauteur de 10.000€. Nous sommes en train de finaliser le dossier de convention. Mais les fonds seront rapidement disponible. C'est une première étape importante pour le projet.

Ensuite, nous passons devant le jury de Share it demain après midi à 16h30 en visio-conférence pour un potentiel mécénat de compétence d'un an de développement. Like tears in rain est peut-être disponible pour m'accompagner mais si quelqu'un d'autre veut/peut se joindre à nous notamment pour la partie technique du projet ce serait super :). N'hésitez pas à me contacter par mail pour que je vous transfère les informations de connexions à la visioconférence.

Pour le moment pas encore de nouvelles de la part de la NLnet foundation. Cela devrait arriver début septembre.

N'hésitez pas à me contacter en cas de question. On pourra se prévoir un point d'étape en visio début septembre si cela vous convient.

Bonne journée,

Rémy Gerbet WMFr (discuter) 23 août 2023 à 12:16 (CEST)

Bonjour @Rémy Gerbet WMFr et tout le monde. Excellente nouvelle ! Merci pour tout le travail de recherche de fonds . Pas dispo demain, désolé. Oui pour un point d'avancement en septembre, quand tout le monde sera rentré de vacances. — Jules* ^discuter 23 août 2023 à 15:48 (CEST)

Hello Rémy Gerbet WMFr Excellente nouvelle ! Je ne suis pas disponible non plus, mais ok pour un point en septembre. Amicalement, JackJackpot (devisons) 23 août 2023 à 16:10 (CEST)

Point d’avancement mécénat Share It

Bonjour tout le monde @Jules*@JackJackpot@Jean-Baptiste Laurent@Like tears in rain@Envel Le Hir@Julien Gardet@Culex @0x010C,

Comme annoncé dans le poste de mois dernier par @Rémy Gerbet WMFr, les premières discutions avec Share It on eut lieu en Août et septembre 2023.

@Envlh et @Rémy Gerbet WMFr étaient présents lors du premier entretient et le second était assuré par @Rémy Gerbet WMFr et moi même.

Suite aux échanges, deux scénarios en sont ressortis:

• Scénario 1: L'outil SWViewer répond en partie au besoin et on pourra partir de cette base pour l'outil LiveRC 2.0 en développant des fonctionnalités additionnelles.
• Scénario 2: L'outil SWViewer n'est pas du tout utilisable en l'état et on fera un développement from scratch.

Bien qu’emballés par le projet, ils ont auraient besoin d'éclaircir plusieurs points:

SWViewer:

Je sais que @Mathis B avais déjà fait une revue de code de SWViewer, et il avait conclu qu'il était difficilement reprenable de part la qualité de son code et de son manque de documentation. Share It aimerait explorer quand même cette piste qui pourrait représenter une bonne réduction des coûts. Du coup, est-ce-que quelqu’un aurait le temps de faire une seconde revue pour avoir au moins un second avis sur la question à leur communiquer?

De plus, bien que l’accès à SWViewer nécessite le statut de révocateur, ils aimeraient, la aussi, avoir un retour d’expérience plus large sur les utilisateurs actuels de SWViewer.

Les besoins:

De plus, concernant les besoins fonctionnels du nouvel outil, il leur semblait judicieux d'avoir un retour plus large que celui des participants au projet LiveRC2.0, incluant plus d'utilisateurs actuels ainsi que des anciens utilisateurs (pourquoi ils ont arrêté de l'utiliser ?) ainsi que des membres de la communauté qui ne l'ont jamais utilisé afin de comprendre leurs raisons.

Pour résumé, ils aimeraient de plus de matière pour prendre la décision d’écarter, ou pas, SWViewer du projet.

Je suis à votre disposition toutes questions ou besoins.

Bonne soirée! Michael Barbereau WMFr (discuter) 19 septembre 2023 à 20:02 (CEST)

 Michael Barbereau WMFr : Bonjour,

Merci beaucoup pour ces bonnes nouvelles.

Il semble donc qu'il faille un maximum de retour des patrouilleurs et des utilisateurs de SWViewer. Comment voudrais-tu collecter ses retours d'expérience ?

Je vais relancer les patrouilleurs.

Jean-Baptiste Laurent (discuter) 21 septembre 2023 à 11:16 (CEST)

Hello. Je me permets de créer des sous-sections pour recueillir ces retours. — Jules* ^discuter 21 septembre 2023 à 13:12 (CEST)

Merci à vous deux. Les sous sections de @Jules* me vont très bien.

Pour info, la prochaine étape d'évaluation sera le 5 octobre.

Il faudrait donc que l'on collecte avant fin septembre que je puisse leur transmettre en amont.

Quelqu'un de motivé et disponible pour compléter la revue de code de SWViewer faite @Mathis B d'ici là? Michael Barbereau WMFr (discuter) 21 septembre 2023 à 18:45 (CEST)

Bonjour @Michael Barbereau WMFr

Même si j'ai un background académique en informatique, je ne suis pas développeur (et encore moins développeur web).

Mais j'ai quand même pu procéder à une revue rapide de code (ce dernier est disponible ici).

My two cents :

• le code est très peu documenté. C'est pas forcément un point bloquant mais il faut derrière que le code soit de bonne qualité.
• je n'ai pas les compétences pour évaluer la qualité intrinsèque du code. Cependant :
  • il y a du travail de découpage et d'externalisation à faire. Un fichier index.php de 1600 lignes, c'est juste pas possible.
  • je trouve néammoins que le noms des fonctions et des modules javascript et php sont assez explicites. Même s'ils ne sont pas documentés, pour un dev web expérimenté, ils devraient être réutilisables.
    

Donc en résumé, je ne pense pas que le code soit totalement inutilisable. Mais il faudra quand même passer du temps à le comprendre et l'assimiler avant de pouvoir réellement le réutiliser.

Amicalement, JackJackpot (devisons) 3 octobre 2023 à 13:56 (CEST)

Je n'utilise que huggle donc pas d'avis Spartan.arbinger (discuter) 27 septembre 2023 à 18:13 (CEST)

Vous êtes patrouilleur/patrouilleuse mais vous n'utilisez pas, ou n'utilisez plus, LiveRC

Pourquoi ? Utilisez-vous désormais un autre outil ?

• La taille des polices est beaucoup plus petite qu'en utilisant "Modifications récentes". Je trouve l'outil actuel peu intuitif voire hermétique, les icônes par exemple sont pour moi incompréhensibles (y compris les messages sous jacents ex : "Afficher/masquer le panneau de débogage"..)--Limfjord69 (discuter) 21 septembre 2023 à 13:39 (CEST)
• Idem, j'ai tenté au début, beaucoup trop dense et hermétique, ergonomie différente du reste de WP. Les "Modifications récentes" avec quelques filtres enregistrés suffisent à mon bonheur. —JohnNewton8 ^{(SysOp) [Viens !]} 21 septembre 2023 à 13:55 (CEST)
• sentiment de lourdeur et lenteur à l'usage. Liverc ne fait pas (il me semble) de préchargement: un clic pour avoir plus d'informations fait attendre. Comparé à WP:Huggle, qui lui a un changement de page instantané puisque tout est chargé avant que l'utilisateur le demande. Il permet aussi une navigation au clavier pour 90% du temps. --Cordialement, -Framawiki ^✉ 21 septembre 2023 à 20:58 (CEST)

Le pré-chargement est tellement efficace qu'il permet de patrouiller sur wikipedia en anglais en même temps que wikipedia en français. Soit près d'une centaine de modifs lisibles par minutes sans problème de performance. Et l'outil gère parfaitement les différences entre wikis, tel que les templates d'avertissement différents. Mais la patrouille multi-wiki est une utilisation particulière des outils

Un autre avantage d'Huggle est l'avertissement par paliers automatique, il va détecter qu'un avertissement de premier niveau ({{faut sourcer}}) a déjà été posté sur la page de discussion du vandale, pour mettre automatiquement le niveau suivant lors du prochain revert ({{test2}}). Il gère aussi l'ajout auto sur WP:VEC après un certain seuil.

L'interface d'Huggle est aussi à plus à mon goût, en restant sobre avec quelques gros boutons principaux, tout en permettant de nombreuses actions avancées en utilisant les menus. Et son automatisation permet de se contenter de cliquer sur le bouton "revert" sans se préoccuper des avettissements ou demande de blocage.

L'idée de la modularité est importante, tant liverc qu'huggle permettent une personnalisation avancée et des plugins personnalisés. Mais peu d'utilisateurs ont exploré cela à ma connaissance. -Cordialement, -Framawiki ^✉ 26 septembre 2023 à 10:40 (CEST)

• Je m'en suis servi durant des années mais ai dû décrocher par manque de temps. Puis, lorsque j'ai voulu m'en resservir, le système m'a paru manquer d'intuitivité et je ne suis plus parvenu à l'utiliser comme avant. Il m'a semblé opaque et moins aisé pour la patrouille que la surveillance des nouvelles créations. Bref, lorsque l'on incorpore le système, il est bon, mais lorsqu'on en décroche, on se rend compte qu'il est difficile de se le réapproprier et qu'ainsi il n'est pas aisé à comprendre. Sans doute que plus d'explications sur ses fonctions seraient nécessaire comme un tuto. Mais après, tout dépend aussi du type de patrouille que l'on effectue. Pour la patrouille de maintenance, il n'est pas forcément utile alors qu'il l'est pour celle des vandalismes à la seconde... Enrevseluj (discuter) 21 septembre 2023 à 23:46 (CEST)
• Même avis que JN8 en ce qui concerne l'ergonomie (dense et hermétique) + je n'aime pas les rafraichissements automatiques d'une fenêtre que je suis en train de lire. J'utilise la page des modifs récentes avec des filtres + le gadget pop-ups qui permet d'y visualiser les diff par simple survol de la souris (pas besoin de cliquer) et en étant révocateur on y a les liens [révoquer] sur la même ligne que les diffs -> c'est pile-poil le besoin... Csar62 (discuter) 25 septembre 2023 à 17:19 (CEST)
• J'utilise peu LiveRC car je trouve l'interface pas très agréable : c'est un surplus d'informations, très dense et en bloc. Les boutons sont pas très intuitifs, la souris est obligatoire (si je ne me trompe), ce qui est dommage puisque avec mon ordinateur portable (Chromebook, donc pas Huggle) j'ai pas toujours une souris de branchée (et le pavé c'est bien 5 minutes mais pour gérer autant de petits liens cliquables c'est assez lourd). J'utilise donc WP:Huggle qui est agréable visuellement selon moi (sans pour autant être surchargé d'informations), on a accès facilement à l'historique d'une personne comme d'une page, il y a pas mal de raccourcis clavier qui réduisent le temps de recherche. Je pense donc que le gros point faible du LiveRC actuellement c'est sa grosse densité en informations et son manque d'intuitivité. SachaKanar ^[discuter] 25 septembre 2023 à 21:07 (CEST)
• J'ai utilisé LiveRC assez régulièrement durant des années de patrouille, et j'appréciais (c'était à l'époque où LiveRC affichait Search and destroy ou shoot'm all ou un truc humoristique du même genre, mais ça été retiré ). Puis j'ai fini par préférer ma liste de suivi, assez conséquente, ainsi que Modifications récentes dont l'aspect sobre me convient pour passer en revue posément ce qui s'est passé. Couplé avec les Popups de navigation pour survoler les diffs, ça me suffit. J'utilise aussi pas mal Wikipédia:Signalement pour voir où ça chauffe et s'il faut intervenir, ainsi que les révocations de Salebot, toujours instructives. Enfin, très souvent je traîne dans Spécial:Journal où on voit tout plein de choses . --—d—n—f (discuter) 25 septembre 2023 à 20:27 (CEST) avis copié depuis là
• J'ai testé un peu LiveRC, et comme d'autres je ne trouve pas l'outil ergonomique ou intuitif. Un truc tout bête : il n'y a pas de titre de colonne sur le tableau principal. Les icônes en haut à gauche sont pas visiblement intuitives. L'interface est trop compacte. Il devrait y avoir des croix sur chaque panneau pour les fermer. Et juste en testant, je viens de comprendre que les boutons en haut à gauche contrôlent les interfaces principales : c'est pas du tout intuitif. Sinon les outils ont l'air utile, il y a plus de fonctionnalités en accès direct avec plusieurs panneaux différents en même temps, c'est pratique. Je pourrais m'y réessayer dans la prochaine version. Pour la patrouille que j'effectue au quotidien, j'utilise les outils donnés par les listes de suivi directement sur le site de Wikipédia, et ça me suffit. J'ai testé SWViewer aussi. Et l'interface est bien plus ergonomique, cependant je ne comprends pas trop ce qu'apporte cette solution en dehors d'une meilleure fluidité par rapport aux navigateurs et quelques fonctionnalités : suivre plusieurs wikis, et des boutons plus ergonomiques. Chouette (discuter) 26 septembre 2023 à 12:50 (CEST)

Vous êtes patrouilleur/patrouilleuse et vous utilisez (toujours) LiveRC

Pourquoi utilisez-vous cet outil ? Quels sont, pour vous, ses avantages et inconvénients ?

• Bonjour à tous. Je trouve que c'est l'outil plus adapté à mes besoins de patrouilleurs pour le moment. Du côté positif, je citerai sa possibilité d'utiliser directement les outils d'administrateurs, la possibilité d'envoyer des messages directement sur les PdD des intéressés, ou encore les différentes indications présentes sur le dif' (utilisateur déjà révoqué ou non, nombre de modifications, nombre d'éditions révoqués, les différents icônes signalant par exemple la présence d'un bandeau R3R ou d'une guerre d'éditions, etc...). Mais en effet il possède des côtés négatifs, comme l'absence de la possibilité de personnaliser "l'espace de travail" et l'absence de mise à jour. Personnellement j'aime tout de même beaucoup cet outil vieillissant. --Martin-78 ^{(discutailler)} 25 septembre 2023 à 16:26 (CEST)
• Bonjour, J’aime bien sa disposition "squelettique", et son aspect "direct". Par contre, la fenêtre de visualisation n’est vraiment pas intuitive (tout comme le nom de certains messages, mais je m’égare). Il serait plus pratique, je crois, que le fait de cliquer sur un lien l’ouvre dans un onglet séparé plutôt que dans le bas. Aussi, il faut un microscope électronique pour l’utilisation sur mobile. --Kirham ^{qu’ouïs-je?} 25 septembre 2023 à 16:52 (CEST)
• Bonjour, j'utilise toujours LiveRC, en complément avec ma liste de suivi. Parmi les nombreux points très positifs de cet outil :
  • La possibilité de voir si un utilisateur a déjà été révoqué récemment, éventuellement plusieurs fois ;
  • La possibilité de personnaliser le message de révocation de plusieurs modifications problématiques à la fois ;
  • La possibilité de paramétrer les modifications notamment par statut d'utilisateur ;
  • La possibilité de traiter le sujet à l'intérieur de LiveRC ou dans l'éditeur de wikicode ;
  • Les balises…
  • Peu d'inconvénients pour moi, c'est un outil très adapté à ce que je fais. --Laurent Jerry (discuter) 25 septembre 2023 à 16:59 (CEST)
• Bonjour, étant passé des modifications récentes à LiveRC, je partage les avis déjà émis ci-dessus, l'outil m'est assez pratique pour la patrouille. J'ajoute à cela la possibilité de faire des demandes de blocage/protection de page/etc… directement depuis LiveRC, ce qui est assez pratique, tout comme l’affichage très visible des nouvelles pages, en vert. Mais il est vrai que sur téléphone, c'est quasiment impossible de l'utiliser… Sinon en terme de fonctionnalités, on ne peut pas appliquer des filtres comme pour les modifications récentes. Aussi, l'esthétique, l'interface est un peu "ancienne" à mon goût. — BimBe93 ^(discuter) 25 septembre 2023 à 18:16 (CEST)
• Bonjour, j'utilise toujours LiveRC car l'outil permet de de configurer précisément la liste des modifications affichées (utilisateurs débutants, blanchiment...) et qu'il est possible d'annuler les modifs rapidement. Le fait de pouvoir demander une suppression immédiate d'une page ou le blocage d'un utilisateur directement depuis l'interface est aussi un avantage important. En revanche, les icônes et les textes ne sont pas intuitifs et portent à confusion, et comme la documentation n'est pas très complète, LiveRC n'est pas facile à prendre en main. Par exemple, alors que la documentation indique qu'il est possible de révoquer plusieurs modifications d'un même auteur, je n'ai jamais compris comment le faire. Aethelflæd (discuter) 25 septembre 2023 à 21:34 (CEST)
• Bonjour, j'utilise toujours LiveRC pour patrouiller, bien que difficile à prendre en main au début il est très ptraique. Seulement quelques icones que je ne comprend pas (qu'est ce que cela signifie quand il y a plusieurs "bonhommes" de couleur au lieu d'un seul ?).--Tormage (discuter) 29 septembre 2023 à 15:01 (CEST)

Vous êtes patrouilleur/patrouilleuse et vous utilisez SWViewer

Pourquoi utilisez-vous cet outil ? Quels sont, pour vous, ses avantages et inconvénients ?

• Mon commentaire en anglais ici. --S4b1nuz ᴇ.656^(SMS) 27 septembre 2023 à 20:39 (CEST)
• …

Actualités recherche de financements/mécénat Septembre 2023

Bonjour à tous,

Je suis ravie de vous informer que nous avons passé la première phase de l'appel à projets de NLnet ! Dans les semaines à venir, ils analyseront notre candidature plus en détail et pourront nous demander plus d'informations. On aura une réponse définitive fin octobre. On vous tiendra informés !

Belle journée, Alejandra Reyes WMFr (discuter) 29 septembre 2023 à 16:24 (CEST)

Question spontanée

'lu, j'ai l'arrogance de ne pas vouloir prendre le temps de tout le lire ici et ailleurs.

Ma question est la suivante : pourquoi il n'a jamais été question de développer une extension de navigateur ? Les gadgets sont bloqués sur les pages spéciales, mais pas les extensions. Construire une surcouche par-dessus la page spéciale des changements récents devrait répondre à la majorité des besoins.

Pas besoin de serveur (hébergé ou non sur les Wikimedia Cloud Services), pas de problèmes de support du système d'exploitation (le problème est déplacé sur le navigateur, mais bon, plus simple à maintenir je pense), possibilité de sauvegarder les paramétrages avec Firefox/Chrome Sync, facilité d'utilisation/installation, sécurité dans le sens où l'extension est isolée dans son processus (bénef' en plus d'avoir naturellement pas besoin de gérer la mémoire), l'extension a une dépendance forte avec un logiciel maintenu continuellement à jour (là où les systèmes d'exploitation ça peut devenir compliqué vu la fragmentation), etc.

Bonne fin de semaine. Lofhi (discuter) 18 novembre 2023 à 09:00 (CET)

Je viens de voir SWViewer, c'est sympa, mais finalement il reste quand même un aspect administrateur système pour distribuer la PWA. L'objectif, cela reste d'avoir le moins de travail à la fin, non ? Une extension mise à jour, c'est publier facilement et automatiquement sur les boutiques des navigateurs Web, au pire il y a un délai de contrôle du code source... Et c'est tout. Il reste la question de la propriété/en quel nom l'extension est distribuée, qu'est-ce qui se passe si celui qui gérait tout se faisait écraser demain. Lofhi (discuter) 18 novembre 2023 à 09:06 (CET)

Ah et pour le contexte : je n'ai pas vu de changements conséquents sur le page des modifications récentes... Depuis son dernier remodelage entier. Autant dire que la page est plutôt stable et qu'il n'y ait pas tellement de risques à travailler dessus ? Lofhi (discuter) 18 novembre 2023 à 09:19 (CET)

Salut @Lofhi et merci pour l'idée. Je manque vraiment de compétence pour avoir un avis sur le sujet. @0x010C, @Like tears in rain, @Jean-Baptiste Laurent et @Mathis B sauront peut-être te répondre. — Jules* ^discuter 16 décembre 2023 à 14:41 (CET)

Actualités recherche de financements/mécénat Décembre 2023

Bonjour à toutes et tous,

Je reviens pour quelques actualités sur le sujet Live RC 2.0. Toutes mes excuses pour les délais mais entre les demandes de financements et autres discussions, le projet n'avance pas très vite. J'avais déjà évoqué le fait que nous avions reçu un financement de Worteks de 10000€ pour le projet. Malheureusement, nous n'avons pas obtenu le financement NL.net. En revanche, nous avons passé toutes les étapes de sélection de Share-it pour avoir un mécénat de compétence et le projet semble vraiment les intéresser. La difficulté que nous rencontrons c'est que, à juste titre, Share-it veut s'assurer que nous sommes en capacité de maintenir le projet dans la durée et par exemple qu'il y aurait à terme une personne recrutée chez Wikimedia France pour mettre à jour et soutenir Live RC 2.0.

Or, il est difficile pour nous de promettre cela aujourd'hui. Le soutien de Share-it est donc suspendu en attendant d'y voir plus clair. En attendant, j'ai aussi pris contact avec les équipes de la WMF pour savoir s'il y avait des projets dans les cartons qui pourraient correspondre aux besoins. Il y a notamment ce genre de projet très interessant en cours de développement. (Anti vandalism App). Pour débloquer la situation l'idée serait peut-être de signer une sorte de partenariat avec la WMF, qui par exemple s'engagerait à soutenir le projet Live RC 2.0. Je suis en attente d'un retour de leur côté sur ce sujet.

Si vous avez des idées d'entreprises que nous pourrions contacter pour demander un soutien financier ou humain, je suis preneur.

Voilà quelques éléments de contexte sur l'état des lieux de nos recherches. Je reste évidemment à votre disposition par mail ou en PDD pour discuter de tout cela,

Amicalement, Rémy Gerbet WMFr (discuter) 19 décembre 2023 à 16:15 (CET)

Bonjour Rémy Gerbet WMFr (d · c) et merci de ce retour détaillé.

Simple curiosité : connait-on les raisons de ces refus ? Est-ce parce que c'est un projet soutenu par une association, l'exigence de licence libre, cette condition d'avoir une personne à la maintenance comme demandé par Share-it ?

Jean-Baptiste Laurent (discuter) 21 décembre 2023 à 09:08 (CET)

Bonjour @Jean-Baptiste Laurent, NL.net finance régulièrement des associations et soutient à 200% l'open source. Ils n'ont pas avancé de raisons particulières si ce n'est je pense une difficulté à comprendre notre mouvement et pourquoi c'était Wikimédia France qui faisait la demande, la problématique de maintien de l'outil a été évoqué mais ne semblait pas forcément être bloquante. Le soucis c'est que c'est une fondation européenne qui répond à pleins de demandes différentes et qu'il a fallu faire un choix. Ils n'ont pas totalement fermer la porte au contraire, ils nous ont invité à revenir vers eux dans les prochains mois au cas où ils auraient du budget supplémentaire. Rémy Gerbet WMFr (discuter) 8 janvier 2024 à 17:35 (CET)

Démonstration de tous les boutons

Je ne suis pas du tout un utilisateur régulier de LiveRC, cependant, j'ai pris 30 min pour appuyer sur tous les boutons avec un regard de novice (désolé). La vidéo est sur Commons :

J'ai pressé un maximum de boutons

Assassas77 (discuter) 16 avril 2024 à 01:12 (CEST)

Démonstration de Live RC à Share-it

Bonjour à toutes et à tous,

On a réussi à avancer un peu avec Share-it ! Ils souhaitent à présent avoir une démonstration de l'outil existant par des patrouilleurs et patrouilleuses aguerries. Ils ont proposé un créneau jeudi 11 juillet à 16h UTC+2 (fuseau horaire de Paris). Y a-t-il parmi vous des gens qui patrouillent régulièrement avec Live RC et qui souhaitent participer à la démonstration ? Adélaïde Calais WMFr (discuter) 4 juillet 2024 à 17:13 (CEST)