Discussion Wikipédia:Prise de décision/AbuseFilter

Avant toute chose merci de prendre connaissance de la page Aide:AbuseFilter.

Un certain nombre d'explications y sont détaillées.

Remerciement préalable...

...à Kropotkine 113 pour le lancement de cette prise de décision, même en tenant compte des embûches qui sépareront la réflexion initiale de l'éventuelle adoption du principe du recours à l'extension AbuseFilter. Nous ne sommes pas au bout de nos peines mais, si tout le monde y met de la bonne volonté, ce principe peut être très rapidement adopté par la communauté, de manière à convaincre les développeurs de mettre en place le système sur wp-FR et, en conséquence, d'offrir à tous des outils supplémentaires appréciables pour lutter efficacement contre des abus de diverses natures sur le wiki. Hégésippe | ±Θ± 19 décembre 2009 à 18:21 (CET)

Merci Je pense qu'on dispose effectivement là d'un outil qui peut rendre de grands services. D'autre part la « lenteur » de la communauté de Wikipédia en français nous permet finalement de discuter d'un système déjà testé à très grande échelle, et donc corrigé des inévitables bugs de lancement, ce qui est un confort appréciable ; et pouvoir s'appuyer sur l'expérience des autres pour nous décider nous-mêmes en toute connaissance de cause n'est pas négligeable. Kropotkine_113 19 décembre 2009 à 18:32 (CET)

Je m'associe également aux remerciements ayant pu constater récemment le besoin de ce type d'outil.--LPLT ^[discu] 20 décembre 2009 à 11:59 (CET)

Merci pour le coup de pied au cul sur le BA qui m'a fait me lancer Kropotkine_113 22 décembre 2009 à 11:40 (CET)

Forme de la proposition

Je ne sais pas si c'est une bonne idée de faire des votes pour les différentes options. Je suis pour la mise en place d'AbuseFilter mais si certaines options sont retenues je serais contre (exemple : filtres visibles par tous, ce qui diminue fortement l'efficacité contre certains vandales). Est-ce qu'on ne devrait pas plutôt faire un vote : pour ou contre la mise en place d'AbuseFilter avec telles options ? On peut rajouter des votes pour des détails secondaires (avec un vote pour le nom, comme ça certains comprendront que c'est une prise de décision importante) et lancer un sondage rapide pour définir les options "fixes" (qui ne seront pas soumises à des votes particuliers dans la pdd). Moyg hop 19 décembre 2009 à 20:01 (CET)

Hmm oui c'est une question que je me suis posée. Le problème du vote « en paquet » (installation plus un jeu d'options) c'est que ça diminue la probabilité d'acceptation (il y aura des gens pour qui les options proposées ne seront pas adéquates). Mais si quelqu'un veut dégager le terrain en faisant un sondage je suis preneur, ça simplifierait la prise de décision.

Ta remarque me fait penser en revanche qu'on peut être plus précis (dans l'aide et dans la pdd) : il est possible de décider pour chaque filtre si les règles du filtre sont visibles publiquement. Les règles d'un filtre à détails publics peuvent être vues par les groupes ayant les droits « Voir la définition des filtres » ; les règles d'un filtre à détails privés ne peuvent être vues que par les groupes ayant les droits « Créer ou modifier des filtres ». Le choix s'effectuant à la création du filtre ou lors d'une modification ultérieure. Peut-être que ça te réconcilie (un peu) avec la formulation de la prise de décision ? Désolé de ne pas avoir été plus clair dans la formulation actuelle et que ce détail m'ait échappé mais c'est justement avec des remarques comme les tiennes qu'on pourra affiner la page d'aide.

Kropotkine_113 19 décembre 2009 à 20:42 (CET)

Ok, je vais essayer de préparer un sondage dans la soirée, ça permettrait d'avoir une meilleure idée de ce que les gens veulent. Moyg hop 19 décembre 2009 à 20:50 (CET)

«Security through obscurity» ça ne marche jamais longtemps... Il vaut mieux rendre les filtres publics et faire des bons filtres. - Gonioul (d) 24 décembre 2009 à 00:30 (CET)

Nouveaux droits introduits par AbuseFilter

abusefilter-private	Option non activée par défaut	Journalise les IP des contributeurs. Non compatible avec la politique de confidentialité de la Wikimedia Foundation.
abusefilter-private-view	Option non activée par défaut	Journalise les IP des contributeurs. Non compatible avec la politique de confidentialité de la Wikimedia Foundation.

Ces droits ne peuvent-ils pas être attribués au groupe des Checkuser, qui ont déjà accès à des données du même ordre ? ⇨ Dr Brains ^{∞ Doléances ∞} 21 décembre 2009 à 14:28 (CET)

Bonne question mais a priori la réponse est non. Lorsque les CU usent de leurs outils tout est journalisé (il est possible de savoir quand ils les utilisent et à quelles données ils accèdent). Ce journal sert à la Wikimedia Foundation pour vérifier qu'aucun CU ne se sert de ses outils d'une façon contraire à la politique de confidentialité. Il n'y a pas de tel journal d'accès aux données de type private de AbuseFilter, donc il n'est pas possible d'activer ces options sur les wikis de la Foundation. En tout cas c'est ce que j'ai compris du problème. Kropotkine_113 22 décembre 2009 à 11:38 (CET)

Quelques questions

Si jamais la participation à ce travail n'est pas réservée à certains groupes (admin, CI), ça m'intéresse de m'impliquer. D'autant que le projet de détection du copyvio que je voulais faire avancer n'a pas démarré cette année.

quelques questions spontanées (je n'ai pas encore fait une recherche extensive sur le sujet hein)

• A partir de quel stade abuse filter devient-il contre-productif en terme de CPU ?
• Existe-t-il une typologie des filtres/des travaux sur le sujet ?
• Si comme le je suppose les algorithmes de filtrage doivent être gardés confidentiels, comment l'équipe de mise au point peut-elle travailler ?
• Même question en prenant en compte le fait que l'on peut bloquer des éditeurs particuliers sur des articles particuliers. Un endroit privé d'échange d'infos sur des personnes, ça fait cabale - cf. un scandale récent de mailing list privée sur en.

--Ofol ^{(moi . ✍)} 22 décembre 2009 à 16:05 (CET)

Le travail à ce sujet n'est a priori réservé à aucun groupe (mais tout dépend ce qu'on appelle travail). Il est en revanche certain que la création/modification de filtres ne pourra pas être laissée libre donc qu'il y aura une restriction à ce niveau. Mais cette restriction peut passer par la création d'un nouveau groupe utilisateur abusefilter ce qui permettrait d'impliquer des personnes non-admin ; sur ce point tout dépend de ce qu'on décidera de faire dans la présente prise de décision. Ce serait à mon avis une très bonne chose, car l'intersection des admin et des compétents risque d'être assez réduite.

Pour le reste de tes questions :

• CPU : je n'ai pas vraiment de compétences techniques à ce sujet ; tout ce que je peux te dire c'est qu'il existe une limite au nombre de conditions qu'on peut combiner dans un filtre (par défaut 1000, mais réglable sur chaque wiki) donc que le problème de la charge induite par le filtrage semble avoir été anticipé par le développeur ;
• typologie/étude sur les filtres : auncune idée. Il faut aller chercher/demander sur en: ou de: qui sont les wikis qui ont la plus grande expérience ; les pages de discussion de en: à ce sujet pourraient t'être utiles (j'en ai lu quelques-unes mais c'est trèèèès long) ; d'autre part Andrew (user:werdna), le développeur de cette extension, peut être contacté ; et enfin on dispose sur fr: de user:Gribeco qui pourra nous faire part de toute son expérience acquise avec Salebot ;
• l'expérience montre que les filtres à définition privée sont finalement assez peu nombreux/nécessaires, sauf cas particuliers de vandalisme au long court et/ou lutte anti-spam ou anti-robots ; on peut traiter l'essentiel du vandalisme de base avec des filtres publics ; en revanche tu poses une très bonne question concernant la discussion autour de ces filtres privés : il est évident que si la définition du filtre est cachée ce n'est pas pour en discuter en détail sur une page publique :) Une mailing-list ou un canal IRC pourraient être utile, mais je le répète l'immense majorité des filtres devrait être, selon moi, publics.
• blocages : je ne suis pas sûr de comprendre la question ; si (ce qui n'est pas sûr) la fonction de blocage est activée, je pense que garder une discussion publique sur l'opportunité de ce blocage est nécessaire et pas forcément contradictoire avec le fait de garder cachée la définition du filtre. D'autre part un utilisateur peut très bien se faire bloquer par un filtre dont la définition est publique, il n'y a alors aucune raison de parler en secret de ce blocage.

Voilà sur ce que je pense moi, mais j'espère que ce sera complété par d'autres. Kropotkine_113 22 décembre 2009 à 17:15 (CET)

merci ! j'ai regardé le filtre de en wp : le système est vraiment très bien fichu, mais c'est beaucoup de travail. Heureusement que l'on va pouvoir récupérer leur code et leur expérience... --Ofol ^{(moi . ✍)} 22 décembre 2009 à 18:50 (CET)

le Throttling est-il une "action" ?

Il est aussi dans cette catégorie sur la page anglaise. Il me semble que c'est un critère de décision, pas une action proprement dite. Même remarque pour Actions restreintes c'est un paramétrage du logiciel, pas une action du filtre (NB cette remarque serait plus à sa place sur Discussion aide:AbuseFilter, mais elle redirige ici) --Ofol ^{(moi . ✍)} 24 décembre 2009 à 19:11 (CET)

Tu as as tout à fait raison sur le fond. Mais d'un point de vue strictement technique le throttling est géré comme une action. Dans l'extension il est activé ou désactivé via la même variable ($wgAbuseFilterAvailableActions) que les actions au sens propre et dans l'interface de gestion des filtres cette option apparaît dans l'encadré « Actions entreprises lors de la détection ». Il est donc apparu plus logique de parler du throttling comme d'une action.

Pour « actions restreintes » on n'a fait que coller aux paramètres techniques ; ces actions sont listées dans $wgAbuseFilterRestrictedActions, d'où la traduction. On peut bien entendu critiquer les choix faits (surtout dans une page d'aide) mais la priorité actuelle est d'obtenir une prise de décision claire à exposer aux développeurs pour qu'ils puissent être certains de la volonté de la communauté quant aux choix de paramétrages : on a donc suivi la philosophie technique du logiciel pour que cet enjeu soit bien celui sur lequel on se focalise. C'est aussi pour cette raison que j'ai redirigée la page de discussion de la page d'aide ici : pour que tout le monde puisse poser des questions et lire les réponses aux problèmes techniques sur une seule et même page dans le but d'éclairer la prise de décision (et cette section va y participer, j'en suis sûr). Quand on aura un jeu de paramètres techniques validés et que l'extension sera installée, on pourra reformuler complètement la page d'aide pour en faire un guide d'utilisation ; en attendant je propose d'en garder la structure quitte à y insérer des commentaires ou des précisions si des passages sont trop vagues/ambigus/techniques (n'hésite pas !). Kropotkine_113 26 décembre 2009 à 11:41 (CET)

tout à fait d'accord ! --Ofol ^{(moi . ✍)} 27 décembre 2009 à 00:51 (CET)

Existe-t-il une typologie des filtres/des travaux sur le sujet

J'ai cherché un peu, voici le résumé d'un papier récent sur le vandalisme sur wikipédia : pour l'instant en anglais et en cours de clarification. Je le mets ici en mind map librement éditable. En gros le papier propose une typologie assez opérationnelle de 10 éléments --Ofol ^{(moi . ✍)} 27 décembre 2009 à 01:03 (CET)

je ne suis pas sûr que le partage de mind map fonctionne bien, je vais attendre un peu pour voir... mais pour l'instant sans être loggé on ne peut apparemment la visualiser --Ofol ^{(moi . ✍)} 27 décembre 2009 à 01:10 (CET)

Je confirme que je ne peux pas voir le document. Kropotkine_113 27 décembre 2009 à 12:40 (CET)

bon apparemment toutes les maps publiques de mindmeister plantent.. je leur ai signalé le problème. Sinon j'ai essayé de faire une Google Wave en utilisant le gadget de mind mapping pour importer la carte sur une wave publique, mais apparemment ce n'est pas encore au point. Si mind meister traine, je peux te l'envoyer au format Freemind (ou sinon je finirai par traduire et publier ici) --Ofol ^{(moi . ✍)} 27 décembre 2009 à 22:37 (CET)

Ah ben si tu me laisses le choix je préfère que tu traduises Kropotkine_113 27 décembre 2009 à 22:41 (CET)

j'ai mis un résumé/brouillon de la typologie me paraissant la plus intéressante ici, je vais aussi en parler à Gribeco --Ofol ^{(moi . ✍)} 2 janvier 2010 à 02:34 (CET)

FAQ1

1. Comment s'appelle(ra) la page des filtres ?
2. Quelle est son équivalent anglophone ou autre ?
3. Sous quelle catégorie de maintenance est-elle rangée ?

TigHervé (d) 4 janvier 2010 à 13:58 (CET)

1. Sur TranslateWiki a été adoptée l'expression « Filtre antiabus », et pour la page principale « Gestion du filtre antiabus » (équivalent de "Abuse filter management") — bien entendu, c'est redéfinissable, là-bas ou en local. Les anglophones ont préféré « Filtre d’édition » ("Edit filter"), sans doute plus explicite.
2. La gestion se fait via page spéciale, en:Special:AbuseFilter ("Edit filter management") / commons:Special:AbuseFilter (« Gestion du filtre antiabus ») ; ainsi que en:Special:AbuseLog ("Edit filter log") / commons:Special:AbuseLog (« Journal du filtre antiabus »).
3. À ma connaissance, aucune du coup.

Jean-Fred (d) 4 janvier 2010 à 14:28 (CET)

Merci donc pour 1, on aura fr:Special:AbuseFilter. TigHervé (d) 4 janvier 2010 à 14:53 (CET)

Sur meta j'ai vu l'expression "journal des abus". Cela veut dire que l'on dit au nouvel inscrit, même celui qui n'a encore jamais contribué qu'on suppose qu'il va commettre des abus. C'est terrifiant cette mentalité de défiance vis à vis d'autrui. Teofilo ◯ 4 janvier 2010 à 17:23 (CET)

On peut tout à fait choisir un autre terme si « abus » paraît mal approprié. Kropotkine_113 4 janvier 2010 à 17:35 (CET)

« Journal des alertes » ? --Acer11 ♫ Χαίρε 5 janvier 2010 à 10:08 (CET)

Pourquoi pas, ou « Journal des erreurs » ? On peut commencer à y réfléchir mais quoi qu'il arrive on pourra en changer quand on veut, les modifications de textes ou de terminologie pouvant être faites n'importe quand et surtout, localement (pas comme l'installation de l'extension en elle-même qu'il faut aller demander aux développeurs). Kropotkine_113 5 janvier 2010 à 12:55 (CET)

L'avantage d'y réfléchir dès maintenant, même si ça ne s'impose pas d'un point de vue technique, c'est bien d'aplanir une réticence partagée par plusieurs. Si ça peut permettre d'installer plus facilement et plus correctement un outil manifestement prometteur en manifestant dans quel esprit c'est fait, c'est pas du temps perdu, je crois. --Acer11 ♫ Χαίρε 5 janvier 2010 à 16:15 (CET) Vu ce que tu as marqué plus bas, Kropott, "journal des erreurs" me va tout à fait !

+0,95.

Il faudrait notamment renommer ou essayer de renommer cette prise de décision (j'ai éliminé « AntiAbus » de la page...). Je ne suis cependant pas d'accord pour tourner autour du pot. Comme déjà dit il n'y a pas de problème pour parler de filtre tout court (une fois que ce sera rentré dans les moeurs) ; il n'y a pas plus de problème pour parler du journal, Journal de ci ou de ça, non la seule question qui vaille est comment nomme-t-on ce qu'AbuseFilter surveille si ce ne sont pas des abus. C'est quoi, ce sont des maladresses, bourdes, dérapages, loupés, aberrations, etc. ? TigHervé (d) 5 janvier 2010 à 16:29 (CET)

pour la terminologie, « Filtre d’édition » me parait assez bien mais j'ai un légère préférence pour « Filtre de publication » : c'est le nom du bouton et édition me parait un peu franglais --Ofol ^{(moi . ✍)} 5 janvier 2010 à 23:19 (CET)

Ça me paraît plutôt bien. Pour le journal, pourquoi pas, tout simplement, « Journal des filtrages » ? Jean-Fred (d) 5 janvier 2010 à 23:45 (CET)

Je parle chinois ? En quoi vos propositions correspondent au besoin ? En quoi, c'est un plus par rapport à filtre ? En quoi, je peux utiliser ce dont vous parlez pour remplacer abus dans une phrase ? Désespérant ! TigHervé (d) 5 janvier 2010 à 23:55 (CET)

Euh, il t'es venu à l'esprit que, peut-être, je n'étais pas d'accord avec toi ? J'ai encore le droit de faire des propositions qui, selon moi, conviennent, ou bien c'est abuser ? Jean-Fred (d) 6 janvier 2010 à 00:14 (CET)

La question n'est pas de savoir qui est d'accord avec qui. L'essentiel de ce fil qui n'a pas été introduit par moi porte sur le caractère péjoratif du terme abus et puisque cela fait accord, j'insiste - moi - pour que ce terme soit remplacé par quelque chose EN RAPPORT. Les déclinaisons autour du mot édition ne sont pas le sujet, même si on peut en parler comme de toute autre chose. On n'a pas besoin d'un synonyme d'édition, mais un synonyme même lointain d'abus ou de quelque chose qui cloche ; on en a besoin pour renommer cette prise de décision et cadrer les choses une bonne fois.

Tu n'es pas d'accord avec moi, ok ! Moi je dis que ça n'avance pas, je peux ? Il faut bien que je donne raison à ceux qui votent contre ma candidature quand même ! XD TigHervé (d) 6 janvier 2010 à 00:27 (CET)

Ben, c'est juste que si on parle de « Filtre de publication », qui filtre les publications, et dont les actions sont consignées dans un « journal des filtrages », rempli de phrases « Machin a déclenché le filtre de publication 12 », on parle plus d'abus nulle part, si ? Problème réglé donc. S'il y a encore des abus qui traînent quelque-part, alors oui, tu as raison d'insister .

Je suis d'accord qu'on s'éloigne un peu beaucoup du terme d'origine, mais c'est pas forcément plus mal, si ? A l'instar de la Patrouille qui est uniquement désignée par des déclinaisons autour de « relu/non-relu ».

Et ça dispense de trouver un terme synonyme de "abus" mais en gentil, car j'avoue, je sèche. Jean-Fred (d) 6 janvier 2010 à 00:50 (CET)

Moi aussi et c'est bien pour ça que ça m'horripile de voir vos talents gâchés sur de faux problèmes. Bien sûr que dans le contexte, on peut dire tout ce qu'on veut de mille façons et que ça ne pose pas de problème. Moi je pense à des échanges loin des filtres quand justement il faudra y penser parce qu'il n'existe pas encore et qu'on a même pas l'idée d'en monter un. Il faut bien dans ces conditions qu'un synonyme d'abus viennent à la bouche : on doit pourvoir dire « vu le nombre de XXXXXXX qui se produisent sur les articles du domaine par emplacement de X par Y, il faudrait voir du côté des filtres à adapter ». Le rêve serait qu'on puisse appeler cette extension AntiXxxxxxx ou filtre de XxxxxxxS !

Merci d'avoir essayé ! TigHervé (d) 6 janvier 2010 à 01:09 (CET)

Hum, oui, c'est très clair et c'est exactement ce que tu disais plus haut, j'ai du lire en diagonale (et c'était pas du chinois ), désolé (en même temps, ce n'était pas vraiment à toi message que je réagissais ^^) Hum, trop de smileys, là..

Tu as tout à fait raison. Mais en fait, ça dépend du contexte, et dans ce contexte ce ne serait pas forcément choquant ? Genre, « Vu le nombre de blanchiments de pages non-justifiés, il faut créer un filtre » ; « Pour prévenir l'utilisateur qui ajoute sa signature par erreur, yaka faire un filtre » ; « Il faut faire un filtre qui bloque les vandales qui ajoutent "$!#@☺X" dans un article ! ».

Sinon, je pense sur l'instant (sans grand enthousiasme) à "Filtre de modifications problématiques" (oué, non, vraiment pas terrible...) Jean-Fred (d) 6 janvier 2010 à 01:47 (CET)

Garanties contre les faux positifs ?

Comme c'est un système automatique, j'imagine qu'il y a des actions parfaitement légitimes qui sont interprêtées par la machine comme un "abus " ou vandalisme. Est-ce le cas ? Et si oui, de quels recours dispose-t-on dans ce cas ? En particulier y a-t-il une possibilité de blanchir le journal des abus pour effacer un faux positif ?

Ne craignez-vous pas la création d'un système qui ternit gratuitement la réputation des gens en inscrivant de manière indélébile qu'ils sont des vandales? Ne craignez-vous pas une sorte de diffamation gratuite, par caprice de robot ? Teofilo ◯ 4 janvier 2010 à 17:13 (CET)

Il y a déjà des faux positifs avec Salebot ou des erreurs des patrouilleurs sans que ça pose de gros problèmes. Ce qu'il faudra c'est utiliser les actions les moins "sévères" pour les erreurs (demander confirmation avant de publier par exemple). Et corriger les filtres en fonction des faux positifs signalés. Le journal des abus n'est pas plus diffamatoire qu'un avertissement de vandalisme laissé par erreur par Salebot ou un patrouilleur (qui restera de manière tout aussi indélébile dans l'historique). Moyg hop 4 janvier 2010 à 17:26 (CET)

Sur une page de discussion, on peut faire venir le dresseur de Salebot pour lui demander de laisser un mot d'explication en regard avec le faux positif, de telle sorte que toute personne qui lit ce faux posifif dans les archives lit en même temps le mot d'explication. Ce n'est pas le cas avec un "journal des abus" qui est non modifiable, qui n'a pas la souplesse d'une page de discussion. Teofilo ◯ 4 janvier 2010 à 17:32 (CET)

J'ai répondu à la question sur les faux positifs plus bas et le blanchiment du journal dans la section en dessous. Kropotkine_113 4 janvier 2010 à 17:38 (CET)

N'est-ce pas la fin du principe Wikipédia:Supposez la bonne foi ?

Créer systématiquement pour chaque compte un nouvel onglet qui s'appelle "filtre des abus" ou "journal des abus", cela veut dire que l'on assimile tout nouvel arrivant (et tous les anciens Wikipédiens au moment où l'on met en place cette extension) à des vandales. D'emblée, on assimile tous les bénévoles à des suspects qu'il faut surveiller.

Je trouve que cela crée une très mauvaise ambiance. Je crois qu'on est en train de transformer Wikipédia qui était quelque chose de bien en un enfer totalitaire où tout le monde surveille tout le monde.

Teofilo ◯ 4 janvier 2010 à 17:19 (CET)

Il y a déjà un « onglet » journal des blocages associé à chaque compte. On n'assimile pas pour autant tous les Wikipédiens à des vandales ayant été bloqués. Moyg hop 4 janvier 2010 à 17:22 (CET)

Oui, comme tout système automatique il y peut y avoir (et il y aura) des faux positifs.

En ce qui concerne leur détection, sur en.wiki.x.io il y a un système de report de faux positifs : chaque action de filtre est accompagnée d'un message liant directement vers une page de signalement de problèmes ; ce système s'ajoute évidemment au fait que tout le monde peut consulter le journal des filtres pour voir si certains cas ne sont pas des faux positifs.

En ce qui concerne l'effacement du journal des abus : ce n'est pas à ma connaissance prévu (mais ça existe peut-être). Mais il faut bien voir une chose : sur le journal il n'est pas utile d'indiquer « utilisateur:machin est un gros vandale » ou tout autre chose stigmatisante. Une annonce-type peut-être celle-ci (reprise encore une fois de en:) :

• 4 janvier 2010 à 18:19 : 95.144.87.75 (discuter) a déclenché le filtre antiabus 172, lors de l’action « edit » sur List of Little Miss characters. Actions prises : Baliser ; Description du filtre : Section blanking (détails) (examiner)

une telle annonce au contenu neutre (« a déclenché le filtre xxx ») ne devrait pas engendrer de problèmes et donc ne nécessite pas de blanchiment.

Pour finir, le problème des inscriptions blessantes est beaucoup plus grave selon moi dans les historiques qui sont attachés de façon définitive à l'article que dans un log technique beaucoup moins visible. Il faut bien entendu dans tous les cas faire attention aux propos tenus, que ce soit par un humain ou par le biais d'un système automatisé ; l'avantage du système automatisé étant qu'une fois établis ses messages de base il ne risque aucun écart de langage ou autre dérapage.

Kropotkine_113 4 janvier 2010 à 17:31 (CET)

Le simple fait d'employer le mot "abus" c'est stigmatisant. Quand on dit de quelqu'un qu'il abuse, c'est rarement très gentil. Teofilo ◯ 4 janvier 2010 à 17:35 (CET)

On peut tout à fait utiliser un autre terme que « abus » si celui-ci ne convient pas. Ou changer complètement la phrase, pourquoi pas. Kropotkine_113 4 janvier 2010 à 17:36 (CET)

Teofilo:Le terme "Abus" vient du nom de l'extension (son créateur l'a appellée comme ça, pourquoi pas). Comme je l'ai dit plus haut, les anglophones ont opté pour "Edit filter" (« Filtre d’édition » / « Filtre de modification »), et ça me paraît personnellement plutôt pas mal. Jean-Fred (d) 4 janvier 2010 à 17:57 (CET)

Oui, mais dans tes propositions les mots édition ou modification n'apportent rien je crois, on pourrait donc se contenter de filtre. Ce qu'il faut c'est un terme qui désigne ce qu'est censé contrôler l'extension et qui sera employé sans être attaché à filtre. On doit par exemple pouvoir dire : « il y a un abus une anomalie (une aberration) que je souhaite contrôler avec AbuseFilter. » TigHervé (d) 4 janvier 2010 à 18:57 (CET)

Je plussois Teofilo, c'est la philosophie première de WP qui change petite touche par petite touche. Nous avons déjà largement mis à mal les deux principes : « osez, n'hésitez pas à contribuez » car « on vous suppose de bonne foi », vous ne risquez rien ce sera sans conséquence ; les blanchiments, les reverts, les SI et les PàS en masse des contributions des nouveaux, et je ne parle pas des IP, qui ont osé et qui sont particulièrement mal récompensés, cela peut même aller jusqu'au blocage par incompréhension des règles que les senseurs ne prennent pas la peine d'expliquer, un bandeau n'a jamais été un modèle de pédagogie.

Il va maintenant y avoir une nouvelle couche : « osez mais n'abusez pas, un bot vous surveille »

Je ne suis pas opposé par principe à la surveillance, mais une surveillance de bon aloi, sans arrière pensée. Il est donc primordial de changer le nom de « filtre anti-abus » qui doit en choquer plus d'un, pour une fois je suis d'accord avec les anglophones, parlons de « filtre d'édition », de « filtre de modification », de « filtre de contribution » ou de « filtre de publication », ce n'est pas les mots suffisamment neutres qui manquent. Si le résultat reste le même, au moins l'état d'esprit est sauf et nous aurons évité de dégrader un peu plus l'ambiance qui est déjà suffisamment pesante comme cela. Merci par avance. Cordialement -- • Hamelin ^{[ de Guettelet ]} • 5 janvier 2010 à 04:27 (CET)

Je suis tout à fait d'accord avec la réflexion sur le nom du système : si on estime que le nom du système est mauvais il en faut changer. Principalement pour deux raisons :

1. la raison que toi et Teofilo évoquez : agressivité, présomption de culpabilité etc. Toutes les idées sont les bienvenues ; pourquoi pas « filtre anti-erreur », ce qui présume la bonne foi ?
2. mais aussi et surtout parce « antiabus » laisse croire que l'interdiction d'un comportement abusif est la seule fonction possible de AbuseFilter. Or c'est faux. Deux exemples :
   • AbuseFilter peut se contenter de baliser une modif pour la signaler à des yeux humains dans les pages de modifications récentes ; voir les balises sur en: : AbuseFilter n'interdit pas la modification mais signale juste qu'une page a été blanchie, qu'un référence a été enlevée, qu'un utilisateur a certainement mal utilisé un bouton de la barre d'édition etc. laissant aux humains la tâche de réparer, d'aider le nouveau ou de révoquer ;
   • AbuseFilter peut être utilisé, par le biais de messages qu'il laisse dans la fenêtre d'édition, comme un système d'aide contextuelle très puissant. Un exemple extrêmement simple et courant : un nouveau modifie un article (ou le crée) et laisse sa signature dans l'article. Je vais essayer de détailler ce qui est possible pour que voyiez l'intérêt :
     • situation actuelle : personne ne lui a dit que c'était mal, la modification est publiée, un patrouilleur la révoque et laisse un bandeau test0 sur la page de discussion du nouveau ; deux entrées pour rien dans l'historique et une possibilité d'incompréhension ou même de mauvaise humeur légitime ;
     • situation avec un filtre bien paramétré : lorsqu'il tente de publier un message apparaît dans la fenêtre d'édition lui disant que signer dans les articles n'est pas l'usage, le message lui demande de retirer la signature et lui donne des liens vers des pages de règles ou d'aide :
       • si le nouveau lit le message et est de bonne foi, il se corrige, publie la modification sans erreur, a appris une règle sans passer par la case prison (et sans toucher les 20000$) ;
       • s'il n'a pas lu le message ou s'il est de bonne foi et n'arrive pas à se corriger, sa modification avec l'erreur est quand même publiée et un patrouiller prend le relai ;
       • s'il est de mauvaise foi il publie volontairement avec l'erreur mais, cerise sur le gâteau, on peut paramétrer le filtre pour ne laisser le droit à l'erreur qu'une fois (ou deux ou trois) et la modification avec l'erreur sera tout simplement interdite au bout de trois insertions de la même erreur dans un certain délai (c'est le throttling ou effet de seuil).

Bref, on peut multiplier les exemples mais bien conçu AbuseFilter est aussi une aide à la contribution, un accueil, un guide automatique pour les nouveaux etc. et pas uniquement un instrument répressif bête et méchant. Tout l'intérêt résidant dans le fait que AbuseFilter peut prévenir avant la modification erronée plutôt que de guérir après celle-ci comme le font Salebot et les patrouilleurs.

Kropotkine_113 5 janvier 2010 à 12:35 (CET)

D'accord avec le caractère péjoratif du terme "abus". C'est certain que l'on pourrait opter pour une formulation plus neutre pour un outil qui, selon moi, doit plus être envisagé comme un assistant d'édition que comme un robot censeur. "Journal des corrections automatiques", par exemple, est moins agressif que "journal des abus".

En revanche, je pense que "supposer la bonne foi" s'applique à tous, pas seulement aux nouveaux, mais également aux membres du groupe autorisé à éditer les filtres. Je suppose a priori que cet outil sera utilisé par des contributeurs de bonne foi pour assister au mieux la communauté. L'avantage de l'automatisation, c'est justement qu'en paramétrant correctement les filtres, on aura automatiquement un message poli, pédagogique, standardisé, sans jugement sur la qualité du contributeur qui commet une erreur, et qui ne dépend pas de l'humeur ou de la disponibilité des patrouilleurs. Ces derniers auront par ailleurs plus de temps à consacrer aux articles et aux vrais vandales, puisque les contributeurs qui abusent se trompent seront systématiquement orientés vers les pages d'aides et autres qui pourraient les aider à mieux comprendre la philosophie et la syntaxe de wp. Pachycephale (d) 5 janvier 2010 à 19:07 (CET)

Possibilité de valider a posteriori une action bloquée par un filtre

Dans le cas où l'on se dirigerait vers une situation où on interdirait complètement certains types de modifications à une certaine catégorie d'utilisateurs (mettons, au hasard, les contributeurs sous IP et ceux inscrits depuis moins de quatre jours), aura-t-on (en tant qu'utilisateur auto-verified, par exemple), la possibilité de rétablir les modifications bloquées via le journal (comme il est aujourd'hui possible d'annuler un revert abusif de Salebot) ? Je n'ai pas l'impression que ce soit le cas sur en: (ceci dit, je ne suis même pas autopatrolled là-bas). Merci d'avance pour tout éclairage sur la question — Arkanosis ^✉ 4 janvier 2010 à 18:00 (CET)

Oui mais il faut que l'option abusefilter-revert soit activée (ce qui n'est pas le cas par défaut). Dans le cas où cette option est activée il faut alors définir quel groupe utilisateur possède le droit d'utiliser cette fonction de révocation. Kropotkine_113 4 janvier 2010 à 18:08 (CET)

P.S.: apparemment sur en: c'est activé mais uniquement pour les administrateurs. Mais on peut choisir ce qu'on veut de « tous les utilisateurs » (y compris IP) jusqu'à sysop, bureaucrate etc. Kropotkine_113 4 janvier 2010 à 18:14 (CET)

Merci pour la réponse . Dans le cas où une l'action « interdire la modification » viendrait à être activée, je soutiendrai l'accès à cette fonctionnalité pour un maximum de contributeurs « fiables ». Je vois mal les seuls administrateurs surveiller les faux positifs h24 — Arkanosis ^✉ 4 janvier 2010 à 18:53 (CET)

Précisions importantes (suite à tes dernières modifs de la prise de décision) : après avoir recherché et repris des renseignements il subsiste finalement un doute quant à ce que fait exactement la fonction revert de AbuseFilter. La première réponse que je t'ai donnée est contradictoire avec d'autres infos. Notamment le droit associé (abusefilter-revert) est documenté comme suit : « Révoquer toutes les modifications effectuées par un filtre antiabus donné » mais la documentation est lacunaire. « Toutes » peut porter sur les actions suite à un déclenchement du filtre ou sur toutes les actions suite à tous les déclenchements du filtre ce qui constituerait une véritable bombe atomique. Du coup je propose de :

• ne pas activer cette option dans l'attente de précision (et on l'activera plus tard),
• activer l'option mais avec un niveau de sécurité max (=réservée admin ou au groupe abusefilter) pour voir de nos yeux comment elle fonctionne et si possible baisser le niveau d'accès uen fois qu'on est sûr.

Kropotkine_113 16 janvier 2010 à 22:58 (CET)

Oula oui, si ça annule tout dans ce sens là, ce n'est effectivement pas souhaitable (sauf filtre défectueux, mais c'est un autre problème). Si je trouve un peu de temps demain (ah non, tout à l'heure en fait, comme le temps passe vite ), j'essairai de m'installer tout ça en local pour tester. — Arkanosis ^✉ 17 janvier 2010 à 00:10 (CET)

Bon alors j'ai fait un peu joujou avec mediawiki et abusefilter, et effectivement abusefilter-revert ne sert qu'à annuler toutes les actions entreprises par un filtre sur une période donnée (et non pas uniquement un déclenchement particulier) .

Dans l'absolu, il y aurait moyen de n'annuler qu'une action en donnant son instant exact de déclenchement, mais ça nécessiterait de donner le droit de tout annuler à tout le monde : beaucoup trop dangereux.

C'est dommage... Il faudra vraiment être extrêmement prudent sur d'éventuels filtres interdisant des modifications (on ne pourra pas être aussi efficace que Salebot du coup — même si ce n'était pas l'objectif). Je crois que je n'ai plus qu'à me plonger dans le code...

Ceci dit, l'option garde un intérêt dans le cas de grosses erreurs et son accès aux abusefilters et aux admins ne serait pas une mauvaise chose (dans le cas où il y aurait deux groupes).

Amicalement — Arkanosis ^✉ 17 janvier 2010 à 17:06 (CET)

C'est bien ce que je craignais. Kropotkine_113 17 janvier 2010 à 17:42 (CET)

Programmation des filtres

Bon, j'ai lu en diagonale l'explication, mais j'ai pas compris une chose: qui crée les filtres ? qui active les filtres ? Merci Snipre (d) 4 janvier 2010 à 18:43 (CET)

Tous les utilisateurs qui ont les droits abusefilter-modify, c'est-à-dire par défaut les administrateurs, mais c'est modifiable : on peut donner ce droit à n'importe quel groupe d'utilisateur reconnu par MediaWiki (utilsateur (dont IP), utilisateur enregistré, administrateur, bureaucrate etc.) ou créer un nouveau groupe utilisateur qui aurait ce droit. C'est à nous de décider qui fait quoi. Voir Aide:AbuseFilter#Groupes d'utilisateurs. Kropotkine_113 4 janvier 2010 à 18:49 (CET)

Ok, merci. Le souci, c'est qu'il faut qques connaissances de programmation, donc donner automatiquement les droits aux admins me semble un peu risqué du point de vue dégâts potentiels, non que je ne les crois pas capables de maîtriser le système, mais il y a sûrement des contributeurs avec une bonne connaissance de la programmation qui ne sont pas sysops, donc un nouveau groupe est nécessaire.

Si nouveau groupe, besoin de nouveaux critères voire système d'évaluation pour nommer des programmateurs. Sais-tu par hasard comment les anglophones nomment leurs responsables ? Snipre (d) 4 janvier 2010 à 19:03 (CET)

Par cooptation des « déjà-éditeurs » compétents si j'ai bien compris la dernière phrase de l'intro de en:Wikipedia:Edit_filter — Arkanosis ^✉ 4 janvier 2010 à 19:13 (CET)

(conflit)

Petit hors sujet avant de te répondre : les administrateurs savent généralement se restreindre à leurs compétences propres : les pages de l'espace MediaWiki sont modifiables par tous les admins, mais en pratique on est une grosse dizaine à y toucher. Bref cet aspect ne m'inquiète pas trop.

En ce qui concerne en.wiki.x.io : les droits de modifications des filtres ont été accordés aux membres du nouveau groupe abusefilter ; l'appartenance à ce groupe est donnée/retirée par les administrateurs (qui peuvent donc se le donner et se le retirer quand ils veulent). La procédure est informelle : le candidat au statut dépose un message dans une page de discussion comme quoi il veut le statut ; s'en suit une discussion d'une semaine en gros et sauf opposition le statut est accordé (voir une exemple). Kropotkine_113 4 janvier 2010 à 19:22 (CET)

Ma remarque n'est pas une critique, mais simplement un rappel qu'il existe des gens très compétents dans le bidouillage de code qui ne sont pas forcément admins et que les admins ne sont pas forcément des contributeurs actifs dans le codage. Moralité, en posant que seul les admins peuvent accéder aux codes, on réduit le nombre de personnes réellement motivées à gérer cet aspect, surtout au lancement du système avec le besoin de se former pour pouvoir éviter les problèmes. Mon commentaire se rapporte plus à la critique mainte fois entendue que les anciens ont des comportements négatifs avec les nouveaux, notamment dans leur manque de soutien face à la complexité de WP. Si à chaque modif que fait un nouveau, il reçoit des messages d'avertissement ou subit des blocages pour cause de code mal fait, on risque de voir le nombre de Wikipédiens diminué faute de relève. N'oublions pas que l'on parle d'un système automatique et que les risques d'interventions sont plus élevées que dans le cas actuel où le comportement des patrouilleurs et autres gardiens est variable. Merci pour les réponses Snipre (d) 5 janvier 2010 à 11:22 (CET)

Je l'entends aussi comme ça : à titre personnel je suis pour que le groupe abusefilter soit utilisé pour la modification des filtres et pour qu'il soit assez ouvert pour les raisons que tu évoques : utilisation des compétences là où elles sont et pondération de l'utilisation du système en ne s'appuyant pas que sur les admins. Kropotkine_113 5 janvier 2010 à 12:10 (CET)

En ce qui concerne l'accueil des nouveaux et l'aide à la contribution j'ai fait une longue réponse plus haut. Notons aussi qu'on n'est pas obligé d'activer la fonction blocage (c'est une option) et que si on prend l'exemple de en: la très grande majorité des filtres se contente de baliser la modification ou d'avertir et non pas d'interdire. Petite précision parce que je ne sais pas si c'est clair : les messages de AbuseFilter sont laissés dans la fenêtre d'édition et non « en dur » dans la page de discussion comme on le ferait nous : ça ressemble beaucoup au bandeau vert qu'on voit quand on prévisualise --> ça peut-être poli, agréable, utile et aider à la contribution :) Kropotkine_113 5 janvier 2010 à 13:05 (CET)

temporisation

Peut-on créer une temporisation avant la validation d'une information liée à la mort par exemple ? Merci. --Thesupermat ^{[you want to talking to me ?]} 4 janvier 2010 à 22:50 (CET)

Pas de manière fiable. Cela demanderait une capacité d'analyse sémantique (un filtre qui détecte qu'une modification est à propos d'une mort) qui n'existe pas. --Gribeco (d) 4 janvier 2010 à 23:40 (CET)

En revanche on peut utiliser l'action marquage (balisage) qui permet à un humain de voir facilement dans les modifications récentes si un ajout concerne potentiellement une information liée à un décès et donc le cas échéant de corriger après vérification. Un peu le journal des modifications suspectes de Salebot mais accessible via les RC. Kropotkine_113 5 janvier 2010 à 12:07 (CET)

Ma question était de savoir s'il était possible qu'une modification basé sur des mots clés pouvait être temporisée pendant une heure ou deux, le temps de laisser un contributeur confirmé valider ou non l'information. Une telle option serait bien pratique et éviterai des désagréments types Philippe Manœuvre. Tant pis, on fera sans. --Thesupermat ^{[you want to talking to me ?]} 5 janvier 2010 à 17:34 (CET)

Le système mis en place sur WP:en et WP:de n’est-il pas précisément ce qu’il faudrait pour éviter ce genre de désagréments (et non un système plus complexe basé sur une analyse sémantique des modifications) ? Il me semble qu’une discussion était en cours depuis plusieurs semaines. — MetalGearLiquid ^{[m’écrire]} 19 janvier 2010 à 13:09 (CET)

Il y a eu un sondage à ce sujet il y a quelques mois, aux résultats plutôt tranchés : Wikipédia:Sondage/Flagged revisions. Jean-Fred (d) 19 janvier 2010 à 13:34 (CET)

En ce qui concerne les FlaggedRevisions Jean-Frédéric a parfaitement précisé où ça en était sur fr: : a priori rejeté par la communauté. Je tiens à rajouter que les deux systèmes n'ont absolument rien à voir et qu'on ne peut pas les comparer ou dire il faudrait les FlaggedRevisions plutôt que AbuseFilter. Ils ne servent pas à la même chose. AbuseFilter, effectivement, ne propose pas de temporisation mais FlaggedRevisions ne propose aucune des fonctionnalités d'un filtre (aide contextuelle, effet de seuil etc.). Kropotkine_113 19 janvier 2010 à 14:02 (CET)

FAQ2 - détails des filtres

Extrait d'Aide:AbuseFilter actuel

Droit	Valeurs par défaut	Description
abusefilter-log	Tous les utilisateurs	Permet de voir le journal d'AbuseFilter (filtre déclenché, page, modification et utilisateur concernés).
abusefilter-log-detail	Administrateurs	Permet de voir les détails du journal d'AbuseFilter.
abusefilter-view	Tous les utilisateurs	Permet de voir les définitions des filtres dont les détails sont publics.

AbuseFilter distingue les droits des utilisateurs (groupes) selon l'accès aux détails, puis selon que ces détails seraient publics ou non. Donc, deux questions de base :

1. Que sont les détails d'un filtre ? Est-ce l'intégralité du programme interprété par l'extension ?
2. Comment se fait le partage entre détails publics et non publics : au coup par coup par filtre ou selon le code utilisé dans les filtres ou ... ?

TigHervé (d) 5 janvier 2010 à 09:27 (CET)

1. ceci j'imagine... Enfin ce sont les détails d'une entrée du journal, pas à proprement parler « d'un filtre ».

Non ce que tu montres ne sont pas les détails du filtre mais les détails du journal ; réponse plus bas. Kropotkine_113 5 janvier 2010 à 12:51 (CET)

1. Au coup par coup, visiblement (une case à cocher dans la page du filtre). — Arkanosis ^✉ 5 janvier 2010 à 10:42 (CET)

1. Y aurait-il donc d'une part les détails d'un filtre et d'autre part les détails de son déclenchement à un moment donné et notés dans le journal. Deux choses bien distinctes, les premiers dépendants de la programmation, les seconds étant le contenu des variables lors du déclenchement.
2. Oui ok, il s'agit d'un flag : « Hide details of this filter from public view ». 2.1 On ne sait pas de quels détails il s'agit ? 2.2 Il serait bon de préciser dans quelle(s) page(s) précisément ces détails sont visibles s'ils ne sont pas cachés. TigHervé (d) 5 janvier 2010 à 11:15 (CET)

1. Oui, les détails du filtre sont visibles si le flag du point 2 n'est pas activé ; les détails du déclenchement sont visibles aux détenteurs du droit abusefilter-log-detail

2.1. Le code source du filtre et les notes associées

2.2. Sur en:Special:AbuseFilter/135 pour le filtre 135, par exemple. — Arkanosis ^✉ 5 janvier 2010 à 11:47 (CET)

(conflit)

Il y a bien deux choses différentes : les « détails du journal » et les « détails du filtre », auxquelles sont donc associés deux droits différents. Pour être plus clair :

• les détails du journal : en gros la base de travail de l'extension, les différents paramètres de la modification analysée dont certains ont déclenché le filtre, etc. ;
• les détails du filtre : ce sont sa définition (son algorithme et ses options) que vous voyez quand les détails de ce filtre sont publics. Voilà ce que vous obtenez quand les détails du filtre ne sont pas publics mais privés : filtre à détails privés.

Le caractère public ou privé d'un filtre est décidé au coup par coup pour chaque filtre et peut-être changé à n'importe quel moment avec une simple case à cocher ou décocher. Voir Aide:AbuseFilter#Publicité des filtres.

Je vais corriger la page d'aide pour que cela soit plus clair. Kropotkine_113 5 janvier 2010 à 11:56 (CET)

Oui avec tout cela, c'est infiniment plus clair. J'espère que mes dernières retouches sont bien dans la ligne de ces éclaircissements (et j'espère que la traduction pour fr: n'importera pas le flou anglophone (même si c'est un flou très relatif et que la pratique dissipe). (Aparte pour toi, il y a deux occurrences d'autopromotion dans la page ; je n'ai pas compris et pense que tu parles ou veux parler d'autoconfirmed...) TigHervé (d) 5 janvier 2010 à 15:21 (CET)C'est OK pour moi. Réponse à l'aparte : l'auto-promotion est le fait de se voir attribuer automatiquement au bout de quatre jours le statut autoconfirmed. Kropotkine_113 5 janvier 2010 à 15:33 (CET)

Le groupe AbuseFilter

Réflexions en vrac, en particulier en écho à ce qui est dit plus haut sur les aptitudes à la programmation.

En fait, ce sont surtout des questions à Kropotkine. Du genre, après l'installation, est-il possible ou facile de modifier les droits des groupes ? par exemple de passer de sysop à AbuseFilter ou de Tous utilisateurs à Autoconfirmed ? Si cela est facile on pourrait différer la création du groupe AbuseFilter...

Si ce n'est pas simple, ne faut-il pas régler les conditions d'entrée pour AbuseFilter, par exemple nombre de contributions pour faire une demande ou nombre de contributions pour que ce soit quasi-automatique ? S'il faut un sondage pour dégager le terrain je peux y penser.

C'est tout pour le moment :) TigHervé (d) 5 janvier 2010 à 17:13 (CET)

Pour changer les droits associés aux groupes utilisateurs il faut impérativement passer par les développeurs. Ce n'est pas très compliqué mais long et pénible : il faut obtenir un nouvel accord de la communauté, déposer un nouveau bug sur bugzilla et on ne maîtrise pas le délai de réponse. Donc, même si tout peut être modifié ultérieurement, mieux vaut que ça soit bon du premier coup. Pour ce qui est de l'accession au groupe abusefilter je ne sais pas trop comment tourner le problème. Ce n'est pas vraiment lié au nombre de contributions ou à l'ancienneté mais plus à la compétence technique et à la confiance dans le contributeur ; donc je suis plus pour quelque chose de très souple sans critères rigides, mais je ne sais pas sous quelle forme précise. Je donne plus haut l'exemple de la façon dont procèdent les anglophones. Peut-être qu'un sondage pourrait aider : comment formalise-t-on les demandes d'accès au statut (page de discut ou bien formulaire en 1000 exemplaires), fixe-t-on des critères ou pas, qui donne/retire le statut (sysops/bureaucrates/autres) ? Kropotkine_113 5 janvier 2010 à 17:29 (CET)

demander une confirmation pour un édit

Bonjour,

ma question est assez proche de celle d'Arkanosis, mais ce que je suggère est encore moins pénalisant pour les contributions :
j'aimerais savoir s'il est possible qu'Abuse Filter affiche un message d'avertissement en réaction à l'activation d'un filtre (une IP vient de blanchir une page ou une section par exemple), demandant au contributeur s'il est sûr de vouloir faire ça ? Je vois deux intérêts à la chose :

1. quasi-disparition des erreurs grossières assimilées à du vandalisme sur l'espace encyclopédique
2. en conséquence de la première, une meilleure détection des vandales, puisqu'une modification type blanchiment sera très probablement un vandalisme et non une erreur. Pour ma part je ne vois guère que les messages d'insulte ainsi que les numéros de téléphone / e-mail qui pourraient être bloqués complètement (ou plutôt, bloqués jusqu'à intervention extérieure, comme suggéré par Arkanosis).
   

Cordialement, Freewol (d) 5 janvier 2010 à 17:29 (CET)

Oui avertir mais laisser la responsabilité de publier au contributeur est possible et c'est d'ailleurs ce qui est le plus utilisé sur en:, certainement pour les raisons que tu exposes. C'est par exemple ce que fait ce filtre de en: ; la case « Empêcher l’utilisateur d’effectuer l’action en question » n'étant pas cochée, l'utilisateur voit un message d'avertissement mais s'il reclique sur « publier » la modification est mise en ligne. En réalité toutes les actions de AbuseFilter sont combinables donc, en ce qui concerne les avertissements, on peut avoir : avertir, avertir/baliser (exemple du filtre que je donne), avertir/interdire etc. Kropotkine_113 5 janvier 2010 à 17:46 (CET)

Merci de tes réponses - je me décide à t'interpeller pour te suggérer vue la redondance des questions de consacrer du temps au bel exemple de 12 h 35 pour en faire une section de la page de prise de décision et d'Aide:AbuseFilter ; ça donne à la fois l'esprit (le tien) et le comment (je dirais une fois pour toute). TigHervé (d) 5 janvier 2010 à 18:24 (CET)

Super, ça a vraiment l'air très complet niveau fonctionnalités. Je pense avoir à peu près les cartes en main pour pouvoir voter. Cordialement, Freewol (d) 5 janvier 2010 à 22:48 (CET)

À propos d'un groupe abusefilter

Créer un nouveau groupe appelé abusefilter permet de faire abstraction des autres statuts - surtout celui d'administrateur - pour la création des filtres antigaffes : contributeurs et administrateurs sont a priori sur un pied d'égalité pour appartenir à ce groupe.

A. Pourquoi un groupe abusefilter ? un groupe capable de concevoir les filtres, y compris les plus problématiques ?

1. pour filtrer les administrateurs qui ne seraient pas aptes techniquement ou portés à jouer les apprentis-sorciers !
2. pour ouvrir la mise au point des filtres à tous les contributeurs compétents !

mais problème des admissions/retraits de ce groupe... et puis, une fois les principaux filtres créés, il ne resterait que les adaptations et mise à jour, ce qui réduirait beaucoup la raison d'être de ce groupe.

B. Pourquoi se passer d'un groupe abusefilter ? les administrateurs étant désignés en lieu et place...

1. parce que une confiance satisfaisante règne de ce point de vue pour les administrateurs, qui connaissent leurs limites et sont prudents a priori !
2. parce qu'il suffit d'une page de requête pour que des contributeurs puissent proposer des filtres mis en oeuvre par des administrateurs !

Inconvénients : la responsabilité des administrateurs s'accroit d'autant et donc s'élèvent les exigences déjà fortes de l'accès au statut et se renforce le dénivelé entre eux et ceux qui n'ont pas ce statut.

Voilà ce que je comprends pour le moment... TigHervé (d) 11 janvier 2010 à 18:38 (CET)

Selon mi, c'est un bon résumé des pour et des contre. Kropotkine_113 16 janvier 2010 à 19:11 (CET)

Presqu'entièrement d'accord. Je pense seulement que

• « une fois les principaux filtres créés », le travail de maintenance et de surveillance des filtres existants représentera un travail important.
• Dans le cas d'un page de requêtes, il faut que les administrateurs qui se chargent de répondre analysent les requêtes qui leur sont faites, ce qui peut prendre presque autant de temps que d'écrire le code correspondant. Ceci dit, c'est le même problème avec un groupe dédié ; cela ne fait que déporter la responsabilité sur d'autres personnes.

Amicalement — Arkanosis ^✉ 16 janvier 2010 à 19:58 (CET)

Simplification de la prise de décision

Salut. J'ai largement simplifié le contenu de la prise de décision et le nombre de sections en effectuant la plupart du temps des choix qui s'appuient sur le valeurs par défaut des paramètres de l'extension. C'est un parti pris, n'hésitez pas à en discuter et à formuler vos objections ici. Tout est discutable. Je repasse ce soir ou demain. Kropotkine_113 10 janvier 2010 à 16:05 (CET)

---

---

Par ailleurs il est décidé que les actions « blocage » et « retrait des statuts » ne peuvent être introduites dans un filtre que par un groupe d'utilisateurs spécifique. »

Salut - ok pour la simplification, sauf que je ressens un fort besoin de clarification des histoires de groupes. Je crois surtout utile d'avoir un développement expliquant abusefilter. Il faudrait préciser que sa constitution concrète supposera des conditions, une procédure ou plusieurs...
Par rapport à l'encadré ci-dessus, il ne s'agit pas a priori du groupe abusefilter même si ce ne peut être que lui s'il est créé ? TigHervé (d) 10 janvier 2010 à 18:58 (CET)

Hmm, oui, il faudrait qu'on réfléchisse à cette histoire de procédure pour attribuer le statut abusefilter et qu'on précise ce qu'on veut. Sinon, pour répondre à ta question concernant les actions actions restreintes (blocage, retrait de statut) : ce peut être n'importe quel groupe utilisateur qui en a les droits, que le groupe abusefilter soit créé ou non. Mais, à la réflexion, je me demande si on ne peut pas simplifier encore plus en évacuant cette question : comme il s'agit de blocage et de retrait de statut il paraîtrait logique que ces actions ne puissent être introduites dans un filtre que par les administrateurs, non ? Kropotkine_113 10 janvier 2010 à 22:55 (CET)

Bonjour - Pour le premier point, j'ai parlé de procédure dans ma suggestion, mais ce n'est pas d'abord ça qui me préoccupe même si je suis prêt à te suivre pour une anticipation de ces questions. Non, je me mets à la place d'un contributeur qui a à peine entendu parler des groupes, qui découvre une extension et un groupe qui porte le même nom, etc., et je me dis que même si on peut se satisfaire d'un vote un peu flou, il serait bon qu'il y ait dans cette page même un résumé des tenants et aboutissants de ce groupe, ou avantages inconvénients pourquoi pas. Il s'agit d'aide ici et maintenant.

2)«  ce peut être n'importe quel groupe utilisateur qui en a les droits, que le groupe abusefilter soit créé ou non. » D'accord en théorie, mais le niveau d'impact étant le même, en pratique si abusefilter est créé, ça ne peut être que lui ?

3) je suis réticent pour consolider l'identité administrateur=blocage ; les administrateurs n'ont pas le « privilège » de bloquer, ils le peuvent en pratique sans que ce soit considéré comme une exclusive à mon sens. Le CAr ou tout contributeur peut décider ou initier un blocage que l'administrateur ne fait qu'entériner. Ensuite, il est question de retrait de statut et il n'y a personne (aucun groupe) qui ait à présent cette possibilité à moins qu'on ne parle de vérification d'adresses (je ne sais pas d'ailleurs...). Donc c'est plus compliqué que ça. Ta question est plus large que ce rappel mais je crois qu'il faut en rester là pour cette réponse avant de l'examiner précisément suite à un nouvel éclaircissement (je note bien que tu parles d'« introduire dans le filtre ») . TigHervé (d) 11 janvier 2010 à 08:48 (CET)

Pas beaucoup de temps pour répondre. Je me contente de :

1) OK il faudra rédiger une petite aide, mais à part le fait que abusefilter est un groupe d'utilisateurs qui auront peut-être certains droits concernant l'utilisation d'abusefilter, on n'a pas grand chose à dire. Je sèche un peu là dessus.

2) Je ne vois pas pourquoi ce ne pourrait être que abusefilter. S'il existe deux droits distincts (modifier les filtres et modifier les filtres qui comportent une action restreinte (blocage, retrait de statut)) c'est que a priori ces droits peuvent être attribués à deux groupes distincts ; exemple : modifier les filtres = abusefilter, modifier les filtres à action restreinte = administrateur. Non ? Mais on peut aussi considérer qu'effectivement cela ne sert à rien de compliquer et que les deux droits sont attribués au même groupe, abusefilter par exemple. Pour moi, plus c'est simple, mieux je me porte, donc je n'ai rien contre ta vision du problème.

3) OK pour ta réticence. C'était une proposition. Mais je rectifie quelque chose concernant le retrait des statuts : àl'heure actuelle sur fr: les administrateurs peuvent retirer un contributeur du groupe exemptés de blocage IP et les bureaucrates peuvent retirer le statut de bot.

Pour éclairer un peut tout ça pour le lecteur qui passerait par là, je mets les liens vers les droits des groupes sur fr: et sur en:.

Kropotkine_113 11 janvier 2010 à 09:24 (CET)

Remarque concernant les actions restreintes ont peut faire encore plus simple : on n'active pas cette option et toutes les actions sont traitées sur un pied d'égalité et peuvent être introduites dans un filtre par le groupe ayant les droits de modification des filtres. Il suffit alors de se décider sur un groupe ayant les droits de modification et c'est tout. Je me demande si ce n'est pas mieux en fait. Kropotkine_113 11 janvier 2010 à 09:47 (CET)

Oui je suis allé un peu vite, pour le point 2 je suis moins convaincu que ce matin. Je laisse tomber provisoirement le groupe d'action restreinte en me concentrant sur abusefilter : dans la section précédente, je fais une synthèse avec/sans, ça servira peut-être pour l'aide et j'attends ta relecture pour compléter éventuellement ou corriger. TigHervé (d) 11 janvier 2010 à 18:38 (CET)

« on n'active pas [les actions restreintes] et toutes les actions [...] peuvent être introduites dans un filtre par le groupe ayant les droits de modification des filtres » Parfait ça — Arkanosis ^✉ 16 janvier 2010 à 19:32 (CET)

Oui plus ça va plus je suis pour cette simplification. C'est le choix effectué par en: notamment. Et au passage je me demande si tout simplement ne pas activer les blocages et retrait de statut ne serait pas plus simple et plus sage dans un premier temps (c'est-à-dire le temps qu'il faudra pour qu'on prenne le truc en main). Sachant qu'on pourra les réintroduire plus tard si la demande se fait sentir. Des avis ? Kropotkine_113 16 janvier 2010 à 20:02 (CET)

D'accord à 200 % (au moins ). Plus sérieusement, dans la mesure où les faux positifs sont inévitables, je pense qu'il est beaucoup plus sage de ne pas laisser à un processus automatique (donc sans capacité de jugement) des droits aussi puissants que bloquer un utilisateur. Il faudra déjà être extrêmement prudent sur les filtres interdisant certains types de contributions...

Et comme tu le dis, il sera toujours temps de se reposer la question lorsqu'on aura un peu de recul sur l'utilisation de filtres moins « offensifs » (tags et avertissements, notamment) — Arkanosis ^✉ 16 janvier 2010 à 21:17 (CET)

Suite à nos discussions j'ai continué mon œuvre de simplification : exit les actions restreintes, exit les blocages et retrait de statut et j'ai aussi limité les choix dans certaines sous-sections concernant les droits utilisateur. J'abuse ? Bien ? Pas bien ? Kropotkine_113 17 janvier 2010 à 19:20 (CET)

J'ai envie de dire « bien », mais j'ai un parti pris — Arkanosis ^✉ 18 janvier 2010 à 14:27 (CET)

Accession au groupe abusefilter

Qu'est-ce que vous pensez d'une demande d'accès au groupe abusefilter un peu similaire à celle d'accès au statut de bot : une petite demande avec une petite durée (une semaine) ? Et que préférez-vous :

• attribution/retrait du statut par les bureaucrates,
• attribution/retrait du statut par les administrateurs ?

Kropotkine_113 16 janvier 2010 à 20:15 (CET)

Dans le cas où il n'y aurais pas de possibilité de blocage à partir des filtres, et uniquement dans ce cas, ça me semble une bonne approche (les personnes déjà impliquées dans ce genre de tâches étant celles qui suivent le plus le processus).

Pour la tâche technique, plutôt favorable à ce que ce soient les bureaucrates qui se chargent de l'attribution ou du retrait du statut. — Arkanosis ^✉ 16 janvier 2010 à 21:23 (CET)

Si on ne pose pas de conditions pour l'accès, on peut faire simple côté candidat comme ce que tu proposes.

Sur le deuxième point, je pense à une solution mi-chèvre mi-chou : la demande est faite sur une page de type RA (ouverte à tous) ; au jour J+x la demande est transmise aux bureaucrates (sans pouvoir discrétionnaire). Pour le retrait, même chose.
TigHervé (d) 16 janvier 2010 à 22:18 (CET)

Tu veux dire une page dédiée Wikipédia:AbuseFilter/Statut (titre mis au pif) ou une page déjà existante comme WP:RA ?

Pour la durée je pense qu'une semaine est bien.

Si pas de pouvoir discrétionnaire alors il faut fixer des critères précis.

Kropotkine_113 17 janvier 2010 à 19:26 (CET)

Je pensais à une page dédiée, mais une fois la mise en place du groupe faite et donc le gros des postulants examiné je pense qu'on pourrait se rabattre sur WP:RA pour les nouvelles candidatures.

Je ne prends pas les choses comme toi : je compte sur une durée assez longue pour que les éventuelles oppositions se manifestent sans que des critères impératifs entrent en jeu (mais des conditions de participations pourquoi pas ; comment estimer quelqu'un qu'on ne connaît pas of course ?). De plus, je ne vois pas à quels critères pertinents tu penses ? en terme de confiance ? de compétence ?

Il faut que ça se passe assez naturellement pour les contributeurs connus et pourtant qu'on ne soit pas ennuyé par des candidatures d'inconnus. TigHervé (d) 17 janvier 2010 à 19:57 (CET)

Par critères je pensais surtout aux conditions selon lesquelles on accepte un candidat : vote ? discussion ? qui décide de dire aux bureaucrates « donnez lui le statut » et selon quels critères ? Moi je suis pour le moins de formalisme possible, une simple discussion m'irait, pour être souple. Kropotkine_113 17 janvier 2010 à 22:05 (CET)

On n'est d'accord, mais on a pas les bons mots (critères/conditions/procédure...). Je crois que les enjeux - si on continue sur la voie de la prudence - ne sont pas tels qu'on ait besoin de complication mais seulement de clarté sur la démarche. Ainsi, je verrais bien sur 10 jours que toute demande est entérinée sauf s'il y a au moins une claire opposition. On est pas sur une PàS ni dans une candidature de bureaucrate :) : au candidat et à son opposant de discuter ; au candidat à patienter, à travailler avec un autre abusefilter pour pallier le rejet et montrer sa motivation-capacité-sérieux- à s'occuper des filtres... ; en attendant une nouvelle demande quand il veut. Selon ce schéma, l'absence d'opposition est facile à lire sur la page et n'importe qui peut relayer la demande aux bureaucrates, candidat compris. TigHervé (d) 18 janvier 2010 à 08:12 (CET)

Oui un mode d'accession sur le principe d'une discussion et avec candidature acceptée sauf si opposition claire me paraît pas mal. Pas trop formel, permet de filtrer un peu mais ne décourage pas les impétrants. C'est bien. Kropotkine_113 18 janvier 2010 à 13:08 (CET)

Je plussoie. C'est à peu près comme ça que ça se passe pour les bots, non ? — Arkanosis ^✉ 18 janvier 2010 à 14:32 (CET)

Groupes d'utilisateurs

Bonjour, y a-t-il une raison pour ne pas inclure le groupe "auto-patrolled" dans les choix pour les droits des utilisateurs selon le groupe ? Merci. Nakor (d) 16 janvier 2010 à 20:28 (CET)

Plusieurs raisons (mais ce sont les miennes donc ce n'est peut-être pas le raisonnement de tout le monde) :

1. ce groupe n'est utilisé, en ce qui concerne AbuseFilter, sur aucun autre wiki (et comme je me suis beaucoup inspiré de ce que font les autres…),
2. je trouve que le choix entre un mode d'accession très facile (ouverture maximale, IP ou autoconfirmed) et un mode d'accession difficile (ouverture restreinte, admins ou groupe abusefilter dédié) couvre tous les besoins. L'idée étant : voir les filtres et les journaux = facile ; créer/modifier le filtres = difficile.

Le groupe autopatrolled me paraît bancal du point de vue de AbuseFilter. Si c'est pour créer/modifier les filtres, un statut qui s'acquière de façon automatique me paraît dangereux. Et en dehors de la création et de la modification, je ne vois pas pourquoi il faudrait attendre 3 mois et 500 modifs pour pouvoir voir le journal ou la définition d'un filtre (sachant qu'on peut toujours cacher le code source d'un filtre qui serait très sensible).

Mais on peut rajouter ce choix pour certains droits, je n'y suis pas farouchement opposé.

Kropotkine_113 16 janvier 2010 à 20:47 (CET)

Vote par approbation

J'ai peur que cette méthode biaise les résultats et pousse au vote calculé. Y a-t-il une contre-indication à utiliser la méthode de Condorcet pour indiquer un ordre de préférence parmi les différentes propositions ? (pour éviter des résultats du genre : 30 % utilisateur, 30 % autoconfirmed, 40 % admin => résultat : admin). Je me charge du problème de la complexité que cela ajoute au décompte, le cas échéant — Arkanosis ^✉ 16 janvier 2010 à 21:35 (CET)

Personnellement je n'ai rien contre Condorcet. Mais j'avais le secret espoir qu'après discussion on n'ait plus que deux choix à proposer pour chaque sous-section et donc que Condorcet soit inutile. Ça n'a pas l'air gagné S'il faut un Condorcet je n'ai rien contre. Kropotkine_113 16 janvier 2010 à 23:09 (CET)

Je comprends mieux le choix binaire « nulle » / « 24 heures » du coup .

Pour « Droit de voir le code-source » et « Droit de voir le détail », on peut déjà retirer une proposition en remplaçant « administrateurs » et « groupe abusefilter » par « groupe possédant les droits d'abusefilter », mais ça fait toujours 3 propositions. — Arkanosis ^✉ 17 janvier 2010 à 14:51 (CET)

J'ai beaucoup plus simplifié. Voir aussi plus haut. J'abuse ? C'est bien ? Pas bien ? Il nous resterait juste un Condorcet. Kropotkine_113 17 janvier 2010 à 19:18 (CET)

Ouverture du vote

Je compte proposer la date du lundi 25 janvier (0h00 CEST) pour l'ouverture du vote. L'objectif étant de refaire une annonce sur le Bistro demain et de faire remonter la prise de décision dans le fil des annonces pour que la communauté relise, critique et pose des questions à propos du texte soumis aux votes, de la page d'aide et de cette page de discussion. Ça nous laisse une semaine pour affiner, rediscuter, répondre aux questions etc. Qu'en pensez-vous ? Kropotkine_113 17 janvier 2010 à 22:10 (CET)

C'est toi qui voit la maturité des choses et il est de bonne méthode de fixer une date puisqu'on peut la repousser sans grand inconvénient. Tu ne verras pas d'inconvénient non plus à ce que j'annonce la fin de la discussion 48 heures avant... TigHervé (d) 18 janvier 2010 à 08:18 (CET)

Idem, je te fais entière confiance.--LPLT ^[discu] 18 janvier 2010 à 12:25 (CET)

Filtre public / privé

Quelles sont les règles envisagées pour définir le caractère privé du code source d'un filtre ? Il y aura des critères pour évaluer sa sensibilité ? Un consensus à obtenir parmi les membres d'un groupe particulier ? Pourra-t-on facilement changer le statut d'un filtre ? Il semblerait que l'expérience sur d'autres wikis montre que très peu de filtres nécessitent d'être privés, tant mieux. Mais qu'est ce qui se passe si un jour on se retrouve avec un troupeau d'éditeurs de filtres paranoïaques qui se mettent tous à penser que leur joujou est ultrasensible et le déclarent privé ? Voter pour savoir qui a le droit de voir le code-source de tout filtre paramétré comme public n'a de sens que si la grosse majorité des filtres est publique. Quelque chose nous le garantit ? Pachycephale (d) 18 janvier 2010 à 00:23 (CET)

C'est une bonne question. La première réponse est, comme toujours sur Wikipédia : le bon sens et l'auto-contrôle. En réalité le problème est le même qu'avec les suppressions de page par les administrateurs : seuls les admins peuvent voir si ce qui a été supprimé devait être supprimé ou pas ; on compte sur l'auto-contrôle des admins et leur diversité pour que le système s'auto-régule, même si absolument rien ne nous garantit qu'ils ne vont pas tous péter un plomb pour se mettre d'accord entre eux et supprimer ce qui les arrange.

D'autre part il suffit qu'une seule personne ayant les droits de modifications (et qui donc peut voir les filtres privés) et qui estime illégitime de cacher le code source pour que la communauté puisse être informée. Il s'agit donc d'un problème de confiance de la communauté envers ceux qu'elle désignera pour paramétrer les filtres.

Le statut public ou privé d'un filtre se change en un clic : il s'agit d'une case à cocher, ce qui peut-être fait très facilement par tout utilisateur ayant les droits de modifications.

Je pense par ailleurs que ne devraient être déclarés privés que les filtres pour lesquels il y a consensus parmi le groupe utilisateur ayant les droits de modifications. Les critères pour qu'un filtre soit privé devraient être par exemple (et selon moi) :

• filtre ayant comme cible un vandale connu de longue durée (172 même s'il n'apparaît plus trop, M.S. etc.) ou un vandalisme connu de longue durée (Noëlistes, goatsex, vandalisme du type ascii art etc.) ;
• filtre anti-robot ou anti-spam.

Tout ceci ne devrait concerner qu'un très petit nombre de filtres. Pour information : en: a environ 300 filtres actifs, à la louche un peu plus d'une trentaine sont privés (≈10%-15%). Parmi ces filtres privés, celui qui se déclenche le plus souvent n'est que le 22^e filtre le plus déclenché. Donc on devrait avoir très peu de filtres privés et qui ne concernent que peu de modifications.

Outre ces aspects l'autre garde-fou (partiel) est : toutes les actions entreprises par un filtre sont journalisées ce qui permet un contrôle a posteriori ; ce journal sera lisible par tout le monde. Quel que soit le caractère public ou privé du filtre il sera possible de visualiser la modification l'ayant déclenché.

Kropotkine_113 18 janvier 2010 à 09:36 (CET)

Merci pour les précisions. Je pensais que seul l'auteur du filtre pouvait modifier son statut. Du moment qu'il est facile de remettre en question le caractère privé d'un filtre, si le besoin s'en fait sentir, ça me convient. Pachycephale (d) 18 janvier 2010 à 18:14 (CET)

Personne n'est jamais propriétaire des filtres, il s'agit toujours d'une gestion collective par groupe d'utilisateurs. Tout ce que fait un membre d'un groupe un autre membre du même groupe peut le défaire. Des fois ça va mieux en le disant Kropotkine_113 19 janvier 2010 à 14:18 (CET)

Changement de nom

Il m'avait semblé ni avoir aucune opposition au changement de nom d'AbuseFilter, alors quand et comment pensez-vous faire ce changement ? Car pour le moment, j'ai plutôt l'impression que l'habitude de l'emploi de ce terme dépréciatif se répand facilement. Merci de la prise en compte de ce détail. Cordialement -- • Hamelin ^{[ de Guettelet ]} • 19 janvier 2010 à 08:17 (CET)

Bonne sollicitation de mon point de vue. Bon, ici et maintenant, ce n'est pas nous qui changerons le nom de l'extension, il est ce qu'il est. Par contre, la prise de décision dure un mois, ce qui suffit si on s'y prend assez tôt pour adapter notre vocabulaire, nos pages, notre langage à nos souhaits. Pour ma part, je vais continuer à soutenir mon point de vue tel que je l'ai fait ci-dessus dans la section FAQ1 : « Il faut bien dans ces conditions qu'un synonyme d'abus viennent à la bouche : on doit pourvoir dire « vu le nombre de XXXXXXX qui se produisent sur les articles du domaine par emplacement de X par Y, il faudrait voir du côté des filtres à adapter ». Le rêve serait qu'on puisse appeler cette extension AntiXxxxxxx ou filtre de XxxxxxxS » ! J'avoue par contre que je n'ai pas beaucoup progressé et que je parle actuellement dans ma barbe en termes « d'AntiGaffes » !! TigHervé (d) 19 janvier 2010 à 10:09 (CET)

J'ai donné mon avis plus haut : je suis pour qu'on trouve un autre terme que « abus ». Moi j'en suis resté à « erreur » mais pourquoi pas « gaffe » (a l'avantage de ne pas trop se prendre au sérieux, ce qui ne serait pas plus mal, mais je ne sais pas si c'est un terme très utilisé en dehors de France).

Quoi qu'il en soit, il y a déjà plusieurs sections qui abordent ce sujet ; on peut lancer un sondage maintenant, ou après la prise de décision, ou pendant. Je suis aussi preneur de toute aide concernant cet aspect particulier, je n'ai que deux bras et malheureusement qu'un seul cerveau

Pour répondre au « quand et comment », c'est simple : dès qu'on a un terme sur lequel on se met d'accord ; ensuite ce n'est pas compliqué de renommer une page et de remplacer un mot par un autre dans les textes (on se chargera de modifier l'interface du système quand celui-ci sera installé). Kropotkine_113 19 janvier 2010 à 14:15 (CET)

Personnellement, je ne vois pas de raison de trouver un autre nom, puisque cette extension existe déjà, et s'appelle AbuseFilter (qui est pour moi un nom propre).

S'il fallait la décrire, pour moi ce serait « gestionnaire de filtres de modifications », et je ne pense pas pouvoir raccourcir : je trouve intéressant de garder la notion de gestionnaire pour ne pas mélanger contenant et contenu, et dire « anti-quelque chose » n'est pas correct pour moi si le mot « modification » n'apparaît pas — d'autant plus que les modifications ne seront pas toutes filtrées de la même manière (il est question de pouvoir en bloquer certaines, de mettre un warning sur d'autres par exemple, si j'ai bien compris), donc le terme « anti » me semble restrictif —.

Enfin bref, je préfèrerais qu'on fasse toujours allusion à cette extension sous son nom, et non sous un synonyme. Cordialement, Freewol (d) 19 janvier 2010 à 14:46 (CET)

PS : le terme garde-fou, utilisé dans une discussion précédant, me semble toutefois intéressant pour décrire succinctement l'extension (dans le sens « Ce qui [[...]] empêche de verser dans l'erreur, dans la faute » donné par le TLFi), même si on ne sait pas comment elle procède.

Comme le dit Hervé on ne pourra pas changer le nom de l'extension donc il ne peut pas être question de ça. En revanche on peut réfléchir à comment parler dans nos pages d'aide et communautaires de ce qu'elle fait, et avec quels termes ce système communique avec l'internaute via son interface. De ce point de vue, éviter le terme « abus » qui est stigmatisant et ne respecte pas la supposée bonne foi des contributeurs est une bonne idée. Et je suis tout à fait d'accord avec toi le préfixe « anti- » est aussi problématique parce qu'il est très restrictif et ne met pas en valeur les nombreuses et diverses possibilités de ce système (dont une forme d'aide contextuelle). Kropotkine_113 19 janvier 2010 à 15:16 (CET)

........ alors si c'est pas Anti-, c'est para-...

........ Si bien que chez moi, pour l'euphonie, AntiAbus devient « ParaCouac » ou « Parecouacs » ! Mais on pourrait aussi chercher un truc en -bot puisqu'il s'agit d'automatismes... TigHervé (d) 19 janvier 2010 à 15:55 (CET)

Les filtres se déclencheront surtout pour les nouveaux (et les vandales, mais eux on s'en fiche ici). Il faut donc un nom qui leur parle et qui leur parait sérieux, et éviter le jargon wikipédien avec des noms en -bot. Quelque chose de simple comme Filtre anti-erreur me parait bien. Je ne pense pas que anti soit gênant puisque même lorsque le système aide le contributeur, c'est pour l'aider à ne pas faire d'erreur. Moyg hop 19 janvier 2010 à 16:22 (CET)

Alors Filtre d'assistance ! TigHervé (d) 19 janvier 2010 à 16:55 (CET)

Un « filtre d'assistance » qui détecterait des « erreurs » ça me paraît pas mal comme combinaison, non ? Y a un peu toutes les idées, j'aime bien. Kropotkine_113 19 janvier 2010 à 17:41 (CET)

@Kropot, me retrouver avec toi sur une PDD ravive en moi quelques mauvais souvenirs mais je vais essayer de te préter tout de même mes bras quant au cerveau ... ça c'est plus problématique -- • Hamelin ^{[ de Guettelet ]} • 20 janvier 2010 à 04:46 (CET)

Merci ! Je suis sûr que cette fois-ci ça va bien se passer. En fait, ça se passe effectivement bien . Kropotkine_113 20 janvier 2010 à 08:36 (CET)

Filtre d'assistance pour un outil qui va interdire certaines modifications, voire bloquer leur auteur, ça fait sacrément orwellien à mon avis. --Gribeco (d) 20 janvier 2010 à 23:05 (CET)

Précisions importantes : la fonction de blocage n'est pour l'instant pas proposée dans cette prise de décision. Pour ce qui est d'interdire, ben, interdire une erreur manifeste qui va rapporter un bandeau test ou un blocage par un admin c'est bien aider quelqu'un, non ? Sans compter que AbuseFilter fait bien d'autre chose que « interdire », qui n'est même pas une utilisation majoritaire du système chez les anglophones. D'après ce que j'y vois c'est bien avertir et baliser qui sont les fonctions les plus utilisées. Kropotkine_113 21 janvier 2010 à 08:32 (CET)

Dans une phrase type « AbuseFilter a listé z abus dans le journal AbuseFilter », ce qui me dérange, c’est la répétition 3× du mot « abus ». Je ne sais pas pour quoi voter, car il faudrait que la phrase puisse 1) donner le nom de l’extension, 2) donner son utilité, 3) que ce ne soit pas lourd ; donc il faut de la cohérence entre les votes. Pour moi, un « Le tamis a listé z écarts de conduite dans le journal AbuseFilter » permet de tout gérer. Nemoi s’est exprimé ici le 20 janvier 2010 à 16:14 (CET)

Pas vraiment. La vraie difficulté est un bon synonyme pour abus parce qu'il suffit pour régler la répétition de ne pas être explicite et donc lourd. Tu peux écrire une phrase minimaliste comme : « Le filtre a enregistré z abus dans le journal. » sachant que filtre sans précision désigne nécessairement ce que j'appellerais moi le filtre d'assistance et que le journal ne peut être que le journal dédié appelé par exemple journal des filtrages ou journal des filtres. Mais explicite ou implicite, le poids de l'équivalent d'abus est patent. TigHervé (d) 21 janvier 2010 à 10:37 (CET)

Sondage rapide pour un changement de nom de AbuseFilter

Il est envisagé de remplacer le terme d'AbuseFilter par une expression considérée comme moins dépréciative permettant de sauvegarder la notion de bonne foi (cf. les sections FAQ1, N'est-ce pas la fin du principe Wikipédia:Supposez la bonne foi ? et changement de nom ci-dessus).

Nota : le nom de l'extension ne pouvant être changé, il s'agit simplement de remplacer dans la rédaction courante le terme « abus » et éventuellement « anti » et en conséquence le nom des interfaces extension/contributeur. Au lieu de « AbuseFilter a listé z abus dans le journal AbuseFilter » nous pourrions écrire « PareCouacs a listé z Gaffes dans le journal des GardeFou ».

Procédure

Mettre uniquement votre signature sous le/les termes recueillant votre/vos préférences. Vous pouvez ajouter d'autres termes ayant vos préférences. Vos observations sont en section discussion. Merci

Liste des proposition déjà faites et quelques autres :

Propositions et avis

Synonyme de « Abus »

• Statu quo : Abus

1. Jejecam (d)
2. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
3. --Ohkami ^[blabla] 20 janvier 2010 à 17:15 (CET)
4. — Rhadamante 21 janvier 2010 à 00:27 (CET)
5. Cantons-de-l'Est 21 janvier 2010 à 12:24 (CET)
6. Vote contre « erreurs ». Nemoi s’est exprimé ici le 22 janvier 2010 à 17:53 (CET)

• Activation de filtre

1. Freewol (d)
2. --Ohkami ^[blabla] 20 janvier 2010 à 17:15 (CET)

• Anomalie

1. Tejgad (d) 22 janvier 2010 à 20:37 (CET)

• Bévue
• Boulette
• Bourde
• Couac
• Écart
• Écart de conduite

1. Nemoi s’est exprimé ici le 20 janvier 2010 à 16:15 (CET) Vote contre « erreurs ». Nemoi s’est exprimé ici le 22 janvier 2010 à 17:53 (CET)

• Erratum
• Erreur

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Pachycephale (d)
4. Cantons-de-l'Est 21 janvier 2010 à 12:24 (CET)
5. Nakor (d) 22 janvier 2010 à 16:40 (CET)
6. MIKEREAD (d
7. Tejgad (d) 22 janvier 2010 à 20:37 (CET)
8. Dodoïste ^{[ dring-dring ]} 23 janvier 2010 à 03:20 (CET)

• Faute
• Faux-pas

1. Totodu74 (devesar...) 20 janvier 2010 à 16:12 (CET)
2. Ο Κολυμβητής (You know my name) 20 janvier 2010 à 18:40 (CET)

• Filtrage

1. Freewol (d)

• Gaffe

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Gz260 (d)

• Impair
• Maladresse

1. Pachycephale (d)
2. MIKEREAD (d)

• Méprise
• Vandalisme

1. Gribeco (d) 20 janvier 2010 à 16:41 (CET)

• .

Discussion

Aura-t-on réellement besoin d'un terme générique pour désigner tout ce qui pourra déclencher un filtre ? — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

Synonyme de « Anti »

• Statu quo : Anti-
• Para-
• Pare-
• .

Discussion

Euh ? — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

Synonyme de « AbuseFilter »

• Statu quo : AbuseFilter

1. Jejecam (d)
2. Freewol (d)
3. Vote principal, mais seulement si le journal n’est pas « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 20 janvier 2010 à 16:17 (CET)
4. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
5. — Rhadamante 21 janvier 2010 à 00:27 (CET)
6. Cdlt, Kyro^{Tok Wiz Mi} le 22 janvier 2010 à 17:55 (CET)
7. Tejgad (d) 22 janvier 2010 à 20:37 (CET)
8. Cantons-de-l'Est 23 janvier 2010 à 04:36 (CET)
9. - DarkoNeko ^{(にゃ? )} 23 janvier 2010 à 10:23 (CET)

• AntiErreurs
• AntiGaffes
• Filtre AntiErreurs
• Filtre AntiGaffes
• Filtre anti-vandalisme

1. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
2. — Rhadamante 21 janvier 2010 à 00:27 (CET)

• Filtre GardeFou
• Filtre d'assistance

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Ο Κολυμβητής (You know my name) 20 janvier 2010 à 18:41 (CET)
4. (ou encore « filtre de prévention » ? par opposition à « répression ») --Wikinade (d) 20 janvier 2010 à 20:18 (CET)

• Filtre de contributions

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Nakor (d) 22 janvier 2010 à 16:40 (CET)

• Filtre d'éditions

1. --Ohkami ^[blabla] 20 janvier 2010 à 09:27 (CET)
2. sans "s" à "édition" Totodu74 (devesar...) 20 janvier 2010 à 16:11 (CET)
3. Nakor (d) 22 janvier 2010 à 16:40 (CET)
4. Sans « s » à « édition » — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

• Filtre de modifications
• Filtre de modifications problématiques
• Filtre de publication

1. -- • Hamelin ^{[ de Guettelet ]} •
2. --Ofol ^{(moi . ✍)} 22 janvier 2010 à 18:51 (CET)

• GardeFou

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 20 janvier 2010 à 16:22 (CET)

• ParaCouacs
• PareCouacs
• Tamis
• Batée
• Agent de publication

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 21 janvier 2010 à 08:38 (CET)

• Filtre à erreurs

1. Dodoïste ^{[ dring-dring ]} 23 janvier 2010 à 13:45 (CET)

Discussion

Synonyme de « Journal AbuseFilter »

• Statu quo : Journal AbuseFilter

1. Jejecam (d)
2. Seulement si le nom retenu n’est pas « AbuseFilter ». Nemoi s’est exprimé ici le 20 janvier 2010 à 16:18 (CET)

• Journal des alertes
• Journal des corrections automatiques
• Journal des erreurs
• Journal des filtrages

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Freewol (d)
4. Gz260 (d)
5. Vote principal. Nemoi s’est exprimé ici le 20 janvier 2010 à 16:19 (CET)
6. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
7. — Rhadamante 21 janvier 2010 à 00:27 (CET)
8. --Ofol ^{(moi . ✍)} 22 janvier 2010 à 18:50 (CET)
9. Tejgad (d) 22 janvier 2010 à 20:37 (CET)
10. Dodoïste ^{[ dring-dring ]} 23 janvier 2010 à 03:21 (CET)
11. Cantons-de-l'Est 23 janvier 2010 à 04:37 (CET)
12. Ou « journal du filtre d'édition » — le filtrage n'ayant pas forcément eu lieu — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

• Journal des activations de filtre

1. Freewol (d)

• Journal du filtre anti-abus

1. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
2. — Rhadamante 21 janvier 2010 à 00:27 (CET)

• .

1. Nakor (d) 22 janvier 2010 à 16:40 (CET)

 

...

Et donc, de base, on n'a pas le droit d'être pour la conservation du terme "AbuseFilter" ? c'est un sacré biais. - DarkoNeko ^{(にゃ? )} 23 janvier 2010 à 01:21 (CET)

Regarde mieux, la première proposition de chaque demande d'avis est le statu quo donc ... -- • Hamelin ^{[ de Guettelet ]} • 23 janvier 2010 à 02:21 (CET)

Statue qui ? =_= - DarkoNeko ^{(にゃ? )} 23 janvier 2010 à 02:24 (CET)

Résultats du sondage

La discussion étant maintenant close, le sondage est clos par la même occasion. Merci aux 23 contributeur qui ont donné leurs avis.

décompte initial

Le décompte des avis se fait en deux temps :

• pour chacune des 4 propositions de synonymes ou statu quo, nous décomptons d'abord globalement les avis pour le statu quo et les avis pour les synonymes (évidement qu'un seul avis à été compté pour ceux qui avaient émis plusieurs avis) ;
• si le statu quo est majoritaire, les avis pour les synonymes ne sont pas décomptés, si le statu quo est minoritaire on retiens le synonyme ayant obtenu le plus d'avis.

Synonyme de « Abus »

• pour statu quo > 7 avis favorables
• pour un synonyme > 14 avis favorables
  • pour erreur > 8 avis favorables
  • gaffe > 3 avis
  • activation de filtre > 2 avis
  • Faux-pas > 2 avis
  • maladresse > 2 avis
  • anomalie > 1 avis
  • filtrage > 1 avis
  • vandalisme > 1 avis

Il y a donc une majorité pour le remplacement de « Abus » par un synonyme et « erreur » a obtenu le plus d'avis favorables.

Synonyme de « Anti- »

• aucun avis

Synonyme de « AbuseFilter »

• pour le statu quo > 9 avis favorables
• pour un synonyme > 13 avis favorables
  • pour filtre d'assistance > 4 avis favorables
  • pour filtre d'édition (sans s) > 4 avis favorables
  • filtre anti-vandalisme > 2 avis
  • filtre de contributions > 2 avis
  • filtre de publication > 2 avis
  • agent de publication > 1 avis
  • filtre d'erreur > 1 avis
  • filtre de prévention > 1 avis

Il y a donc une majorité pour le remplacement de « AbuseFilter » par un synonyme et « filtre d'assistance » et « filtre d'édition » ont obtenu le plus d'avis favorables.

Synonyme de « Journal AbuseFilter »

• pour le statu quo > 2 avis favorables
• pour un synonyme > 13 avis favorables
  • pour journal des filtrages > 12 avis favorables
  • journal du filtre anti-abus > 2 avis
  • journal des activation de filtre > 1 avis
  • journal du filtre d'édition > 1 avis
  • ... > 1 avis

Il y a donc une majorité pour le remplacement de « AbuseFilter » par un synonyme et « journal des filtrage » a obtenu le plus d'avis favorables.

Au lieu de « AbuseFilter a listé z abus dans le journal AbuseFilter » nous devrions pouvoir écrire « le filtre d'assistance/d'édition a listé z erreurs dans le journal des filtrage ».

Cordialement. -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 04:00 (CET)

 

Deux résultats sont tirés de la consultation : un rapport indicatif sur la volonté de conservation du statu quo, et un classement des propositions.

Synonyme de « Abus »

• pour statu quo > 7 avis favorables
• pour un synonyme > 14 avis favorables

Résultat : pas de majorité pour le statu quo, 1/3 pour

Propositions

• erreur > 8 avis favorables
• abus > 7 avis favorables
• gaffe > 3 avis
• activation de filtre > 2 avis
• Faux-pas > 2 avis
• maladresse > 2 avis
• anomalie > 1 avis
• filtrage > 1 avis
• vandalisme > 1 avis

Analyse
Le tiers des votants accepte de statu quo « Abus ». Le synonyme « erreur » a cependant obtenu le plus d'avis favorables.

Synonyme de « Anti- »

• aucun avis

Synonyme de « AbuseFilter »

• pour le statu quo > 9 avis favorables
• pour un synonyme > 13 avis favorables

Résultat : pas de majorité pour le statu quo, un peu plus de 1/3 pour

Propositions

• AbuseFilter > 9 avis favorables
• filtre d'assistance > 4 avis favorables
• filtre d'édition (sans s) > 4 avis favorables
• filtre anti-vandalisme > 2 avis
• filtre de contributions > 2 avis
• filtre de publication > 2 avis
• agent de publication > 1 avis
• filtre d'erreur > 1 avis
• filtre de prévention > 1 avis

Analyse
Comparé au cas « Abus », à peu près la même proportion de votants s’est exprimé pour le statu quo. Cependant, la proposition est largement majoritaire du fait du partage des avis opposés entre « filtre d'assistance » et « filtre d'édition ». Le remplacement de « AbuseFilter » sera envisageable si une proposition opposée arrivait à sortir du lot.

Synonyme de « Journal AbuseFilter »

• pour le statu quo > 2 avis favorables
• pour un synonyme > 13 avis favorables

Résultat : large proportion pour le remplacement du statu quo

Propositions

• pour journal des filtrages > 12 avis favorables
• journal du filtre anti-abus > 2 avis
• Journal d’AbuseFilter > 2 avis favorables
• journal des activation de filtre > 1 avis
• journal du filtre d'édition > 1 avis
• ... > 1 avis

Analyse
Une large proportion des votants n’accepte pas le statu quo. L’avis « journal des filtrages » est largement plébiscité.

Résultat

Au lieu de « AbuseFilter a listé z abus dans le journal AbuseFilter » nous devrions pouvoir écrire « AbuseFilter a listé z erreurs dans le journal des filtrage ».

Nemoi s’est exprimé ici le 24 janvier 2010 à 17:59 (CET)

Une remarque : personnellement, j'avais pas compris qu'il y avait deux votes, 1) pour ou contre le remplacement, 2) quel terme à choisir. Parce que si on considère qu'il n'y avait qu'une question, le résultat, c'est plutôt « Abusefilter a listé z Abus/erreurs' dans le journal des filtrage ». --Ohkami ^[blabla] 24 janvier 2010 à 07:58 (CET)

J'irais même plus loin en disant que c'était simplement une consultation destinée à faire émerger quelques propositions, en aucun cas un mécanisme de décision. En tout cas il n'avait pas été annoncé comme tel, et il serait bien imprudent d'en tirer des conclusions de ce fait. Cordialement, Freewol (d) 24 janvier 2010 à 08:55 (CET)

Houla. Exactement la même remarque que Okhami. Pour moi on s'oriente vers une phrase dans le journal du type :

1. 4 janvier 2010 à 18:19 : 95.144.87.75 (discuter) a déclenché le filtre anti-erreur 172, lors de l’action « modifier » sur List of Little Miss characters. Actions prises : Baliser ; Description du filtre : Blanchiment de section (détails) (examiner)

Le journal s'appelant « journal des filtrages » et le système mis en place gardant le nom de l'extension AbuseFilter. Par ailleurs on ne peut pas séparer en deux les votes, les votes statu quo d'un côté, le reste de l'autre : 1) ce n'était absolument pas clair 2) surtout pas quand plusieurs choix étaient possibles (ce qui introduit évidemment un biais si on fait la somme de toutes les propositions autres que statu quo ; exemple : je vote dans toutes les sections autres --> j'empêche le statu quo à moi tout seul !).

Pour finir n'oublions pas que rien n'est irrémédiable, on peut toujours discuter plus avant de ces questions et améliorer encore la terminologie plus tard (quand l'extension sera installée) ; mais au moins on ne part pas de rien. Kropotkine_113 24 janvier 2010 à 11:49 (CET)

Également très contre la manière dont la comptabilisation des voix est faite. « AbuseFilter » reste le nom de l’extension, à 9 avis contre 4. Toute argumentation contraire est du WP:POINT. Nemoi s’est exprimé ici le 24 janvier 2010 à 11:56 (CET)

He ho ! On se calme… c'est une discussion Pas besoin de sortir des trucs du genre POINT ou chais pas quoi, keep cool, on peut ne pas être d'accord et s'expliquer gentiment sans sortir les armes. Il est encore heureux qu'on puisse avoir un « argumentation contraire » sans se faire sauter dessus, non ? Kropotkine_113 24 janvier 2010 à 12:13 (CET)

Personnellement, je trouve que le "garder les noms actuels" aurait du être mis à part ; j'veux dire je les ai même pas trouvé au départ... - DarkoNeko ^{(にゃ? )} 24 janvier 2010 à 12:44 (CET)

Disons qu’un peu de maîtrise des statistiques montre bien que le raisonnement appliqué cherche à exclure le statu quo — un comble — des votes possibles. En effet, à le comparer d’abord aux autres possibilités, chaque voix pour n’est plus comptée qu’à environ l’inverse du nombre de voix exprimées contre… Nemoi s’est exprimé ici le 24 janvier 2010 à 13:15 (CET)

Fatigué, wikilove, désolé, touça. Je reprend : la technique de comptage ne met pas sur le même plan les votes statu quo avec ceux des autres possibilité. La proposition initiale a des avantages et des désavantages, mais chaque contributeur votant pour elle a pesé le pour et le contre. Il n’y a donc pas de raison de ne pas mettre sur le même plan les votes des uns et des autres. Nemoi s’est exprimé ici le 24 janvier 2010 à 13:23 (CET)

Waouh ! Juste un peu de calme SVP, d'abord ce n'est qu'un sondage qui n'est pas gravé dans le marbre, de plus je n'ai cherché à exclure aucune option, pas plus le statu quo que l'emploi d'un synonyme, si ma présentation a mal été interprétée, j'en suis désolé et vous prie de m'en excuser.

Maintenant, regardons les choses en face, il me paraissait évident que la question qui se posait, pour ceux qui avait suivi la discussion et les liens donnés sur le bistro pour le lancement du sondage, était d'abord de savoir si l'on changeait les termes d'usage, et non de l'extension, et ensuite de savoir quel terme utilisé.

Si vous remarquez bien ma façon de décompter les avis, en ne comptant qu'une seul fois les avis pour déterminer statu quo/synonymes, je peux démontrer, pour faire plaisir à Nemoi (au fait tu connais « présupposer la bonne foi » ?), que si le sondage avait été scindé en deux parties, les résultats auraient été sensiblement les mêmes, sauf à vouloir influencer les résultats et donner un avis « stratégique ».

Maintenant vous avez toujours la possibilité d'utiliser des termes stigmatisant les comportements des contributeurs, c'est juste un problème d'état d'esprit. Et je pense que de « bien » ou « mieux » considérer les contributions de ceux qui n'ont pas vos compétences ou vos connaissances de WP, serait un vrai plus pour cette encyclopédie, ... à commencer par ceux qui ne savent pas présenter un sondages comme vous le voudriez .

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 13:55 (CET)

Non, la question à se poser est « quelle phrase doit apparaitre au final ». Tout le monde est d’accord, jusque là ?

Tu ne peux pas faire un seul sondage pour savoir 1) si on élimine ou pas le statu quo et 2) quel terme choisir ; car alors, ceux qui voudraient voir apparaitre le terme présent par défaut sont exclus des votes du choix du nom dans le cas où une majorité de personne est pour un changement.

Au cas où je ne suis pas bien clair, je fais par l’exemple : je préfére le nom « filtre anti-vandalisme » à celui de « filtre d’édition ». Avec la technique employée actuellement, mon avis n’est pas pris en compte. Oui, car ma préférence n’est pas sur un pied d’égalité avec la tienne… étrange, d’ailleurs…

Soit on fait deux sondages, et en ce cas toutes les personnes ayant voté pour le statu quo ont le droit de donner un avis sur le nom, soit on fait un seul sondage en considérant le statu quo comme une option.

Or, le fait que le sondage ait proposé les noms plutôt que de poser une question en oui/non faisait clairement ressortir qu’on était dans le deuxième cas. C’est d’ailleurs la manière la plus logique de procéder, puisque « AbuseFilter », « Journal d’AbuseFilter » et « Abus » sont des propositions comme les autres…

Soit je te considère peu au point avec les statistiques, soit je te considère de mauvaise foi. Et je ne le retire pas, celui-là. Tu préfères quoi ?

Nemoi s’est exprimé ici le 24 janvier 2010 à 16:18 (CET).

Edit : mise en avant de la phrase principale de mon post. Nemoi s’est exprimé ici le 24 janvier 2010 à 16:55 (CET)

Dans le choix que tu me laisses, je ne préfère rien et surtout pas la polémique pour un sondage qui n'a en fin de compte qu'un avis indicatif. Je trouve beaucoup plus important l'état d'esprit que nous entretenons au sujet de la participation des contributeurs non rompus aux arcanes de WP. Et en l'occurrence, je parle d'expérience, j'ai commencé ma participation au projet par un conflit sur une PDD, par ignorance des subtilités de wp ; ... apparemment je ne me suis pas beaucoup amélioré . Cordialement -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 17:29 (CET)

Donc tout le monde est d’accord pour dire que « AbuseFilter » est ressorti comme avis principal au sondage, n’est-ce pas ?.. Nemoi s’est exprimé ici le 24 janvier 2010 à 17:47 (CET)

Tout le monde ? Je ne sais pas, il faudrait faire un sondage Mais moi c'est que je lis du sondage, oui. AbuseFilter/Erreur/journal des filtrages semblent être la combinaison favorite. (Et c'est ce que je disais déjà ce matin…) Kropotkine_113 24 janvier 2010 à 17:52 (CET)

J’ai corrigé. Nemoi s’est exprimé ici le 24 janvier 2010 à 18:00 (CET)

@Nemoi, soit au moins logique jusqu'au bout en indiquant qu'il n'y a pas de majorité pour remplacer AbuseFilter, retire aussi la première ligne indiquant un vote en deux parties (ce n'est as un vote, et il n'est plus en deux parties) et les trois premières lignes, « pour le statu quo », « pour un synonyme » et « résultat » de chacune des trois sections. Que les choses soient aussi claires que tu le souhaites. Cordialement -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 18:36 (CET)

Je n’avais pas tout fait bien, c’est vrai. Deuxième essai. Nemoi s’est exprimé ici le 24 janvier 2010 à 19:23 (CET)

Travaux pratiques

Travaux pratiques

Pour prendre le cas le plus disputé :

Synonyme de AbuseFilter

en retirant les votes doubles dans « contre » (Gribeco et Rhadamante) mais en les laissant dans « pour »

pour :

1. Jejecam (d)
2. Freewol (d)
3. Nemoi s’est exprimé
4. Gribeco (d)
5. Rhadamante
6. Kyro^{Tok Wiz Mi}
7. Tejgad (d)
8. Cantons-de-l'Est
9. DarkoNeko ^{(にゃ? )}

contre :

1. • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Ο Κολυμβητής (You know my name)
4. Wikinade (d)
5. Nakor (d)
6. Ohkami ^[blabla]
7. Totodu74 (devesar...)
8. Nakor (d)
9. Arkanosis ^✉
10. --Ofol ^{(moi . ✍)}
11. Dodoïste ^{[ dring-dring ]}

Qui aurait voté différemment sans contredire son vote suivant ?

Choix d'un synonyme :

• Filtre anti-vandalisme

1. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
2. — Rhadamante 21 janvier 2010 à 00:27 (CET)

• Filtre d'assistance

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Ο Κολυμβητής (You know my name) 20 janvier 2010 à 18:41 (CET)
4. (ou encore « filtre de prévention » ? par opposition à « répression ») --Wikinade (d) 20 janvier 2010 à 20:18 (CET)

• Filtre de contributions

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Nakor (d) 22 janvier 2010 à 16:40 (CET)

• Filtre d'éditions

1. --Ohkami ^[blabla] 20 janvier 2010 à 09:27 (CET)
2. sans "s" à "édition" Totodu74 (devesar...) 20 janvier 2010 à 16:11 (CET)
3. Nakor (d) 22 janvier 2010 à 16:40 (CET)
4. Sans « s » à « édition » — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

• Filtre de publication

1. -- • Hamelin ^{[ de Guettelet ]} •
2. --Ofol ^{(moi . ✍)} 22 janvier 2010 à 18:51 (CET)

• GardeFou

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 20 janvier 2010 à 16:22 (CET)

• Agent de publication

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 21 janvier 2010 à 08:38 (CET)

• Filtre à erreurs

1. Dodoïste ^{[ dring-dring ]} 23 janvier 2010 à 13:45 (CET)

 

CQFD, Cordialement -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 14:32 (CET)

Travaux pratiques

Travaux pratiques

Pour prendre le cas le plus disputé :

Synonyme de AbuseFilter

en retirant les votes doubles dans « contre » (Gribeco et Rhadamante) mais en les laissant dans « pour »

pour :

1. Jejecam (d)
2. Freewol (d)
3. Nemoi s’est exprimé
4. Gribeco (d)
5. Rhadamante
6. Kyro^{Tok Wiz Mi}
7. Tejgad (d)
8. Cantons-de-l'Est
9. DarkoNeko ^{(にゃ? )}

contre :

1. • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Ο Κολυμβητής (You know my name)
4. Wikinade (d)
5. Nakor (d)
6. Ohkami ^[blabla]
7. Totodu74 (devesar...)
8. Nakor (d)
9. Arkanosis ^✉
10. --Ofol ^{(moi . ✍)}
11. Dodoïste ^{[ dring-dring ]}

Qui aurait voté différemment sans contredire son vote suivant ?

Choix d'un synonyme :

• Filtre anti-vandalisme

1. Gribeco (d) 20 janvier 2010 à 16:43 (CET)
2. — Rhadamante 21 janvier 2010 à 00:27 (CET)

• Filtre d'assistance

1. -- • Hamelin ^{[ de Guettelet ]} •
2. Kropotkine_113
3. Ο Κολυμβητής (You know my name) 20 janvier 2010 à 18:41 (CET)
4. (ou encore « filtre de prévention » ? par opposition à « répression ») --Wikinade (d) 20 janvier 2010 à 20:18 (CET)

• Filtre de contributions

1. Jejecam (d) avis si on abandonne le statu quo
2. Freewol (d) avis si on abandonne le statu quo
3. Nemoi s’est exprimé avis si on abandonne le statu quo
4. Gribeco (d) avis si on abandonne le statu quo
5. Rhadamante avis si on abandonne le statu quo
6. Kyro^{Tok Wiz Mi} avis si on abandonne le statu quo
7. Tejgad (d) avis si on abandonne le statu quo
8. Cantons-de-l'Est avis si on abandonne le statu quo
9. DarkoNeko ^{(にゃ? )}
10. -- • Hamelin ^{[ de Guettelet ]} •
11. Nakor (d) 22 janvier 2010 à 16:40 (CET)

• Filtre d'éditions

1. --Ohkami ^[blabla] 20 janvier 2010 à 09:27 (CET)
2. sans "s" à "édition" Totodu74 (devesar...) 20 janvier 2010 à 16:11 (CET)
3. Nakor (d) 22 janvier 2010 à 16:40 (CET)
4. Sans « s » à « édition » — Arkanosis ^✉ 23 janvier 2010 à 14:33 (CET)

• Filtre de publication

1. -- • Hamelin ^{[ de Guettelet ]} •
2. --Ofol ^{(moi . ✍)} 22 janvier 2010 à 18:51 (CET)

• GardeFou

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 20 janvier 2010 à 16:22 (CET)

• Agent de publication

1. Vote secondaire, si le journal est « journal d’AbuseFilter ». Nemoi s’est exprimé ici le 21 janvier 2010 à 08:38 (CET)

• Filtre à erreurs

1. Dodoïste ^{[ dring-dring ]} 23 janvier 2010 à 13:45 (CET)

 

CQFD Nemoi s’est exprimé ici le 24 janvier 2010 à 16:22 (CET)

Cette façon d'interpréter les avis des contributeurs ne changerait éventuellement que le choix d'un synonyme mais pas le choix primaire pour ou contre le statu quo. Il me semble pourtant que tu avais bien compris le mécanisme toi qui a été le seul à porter des votes/avis secondaires motivés. Cordialement -- • Hamelin ^{[ de Guettelet ]} • 24 janvier 2010 à 17:36 (CET)

C’est tout à fait exact, c’est un raisonnement pour démontrer que la manière de procéder fausse les résultats.

La bonne manière de procéder consiste à prendre à égalité toutes les propositions. Nemoi s’est exprimé ici le 24 janvier 2010 à 17:45 (CET)

Articulation avec Salebot ?

Je suis étonné de ne pas voir clairement dans la discussion une comparaison avec Salebot, et savoir quelles sont les fonctionnalités complémentaires, ou redondantes, de l'un ou de l'autre. Pour moi en tout cas, les différences avec Salebot ne sont pas du tout claires; quand je lis la description de AbuseFilter dans la description de cette prise de décision, je crois lire les spécifications de Salebot. Quelqu'un peut-il répondre aux questions suivantes :

• Qu'apporte AF de plus que Salebot ? Pourquoi Salebot n'est pas suffisant ?
• Que deviendra Salebot si AF est mis en place ?
• Pourquoi faut-il une prise de décision pour AF, alors que Salebot a été mis en oeuvre sans une telle démarche ? (si je ne m'abuse). Est-ce qu'il y a des "dangers" ou des difficultés que Salebot de pose pas ?

Merci d'avance pour vos réponses. Jean-Christophe BENOIST (d) 24 janvier 2010 à 20:42 (CET)

Bon je réponds par suppléance puisque Kropot n'est pas en ligne.

L'avantage essentiel de l'extension est qu'elle nous met à l'abri des défaillances de Salebot ou plutôt du hard sur lequel il tourne, voire d'une défaillance de Gribeco son dresseur.

Point 2, je pensais que nous aurions pu remercier Salebot de ses services et de son zèle, mais j'ai cru comprendre qu'il serait encore utile. J'attends de savoir en quoi.

Point 3. Salebot était un robot interne au projet, l'extension est un outil externe dont l'installation n'est faite que sur preuve du désir de la communauté, en clair sur le résultat positif de la prise de décision.
TigHervé (d) 24 janvier 2010 à 22:35 (CET)

J'ai fait un petit comparatif dans la page d'aide : aide:AbuseFilter#Différences entre AbuseFilter et Salebot. Mais je peux redétailler quelques points ici.

• En plus de l'absence de panne que cite Hervé, AbuseFilter possède comme avantages sur Salebot :
  • le fait d'avertir dans la fenêtre d'édition avant publication (Salebot n'agit jamais qu'après coup), ce qui peut constituer une aide contextuelle assez puissante si elle est bien conçue (je m'apprête à mettre en ligne une bourde le logiciel me prévient avant que je ne le fasse définitivement et m'informe sur comment m'auto-corriger),
  • le fait de pouvoir baliser des modifications dans les pages de modification récentes (et tous les utilisateurs peuvent lire ces balises dans les RC) ; exemple : un utilisateur supprime des références dans un article, je suis en train de lire les pages de RC, une balise m'en informe, je peux aller vérifier de quoi il retourne etc. on peut voir cela comme une grosse amélioration du système de patrouille : l'humain reste le seul décideur mais AbuseFilter lui indique directement dans les pages de RC les modifs les plus susceptibles d'être problématiques,
  • le fait d'empêcher un vandalisme trivial et sans ambiguïté avant qu'il soit mis en ligne : laisse l'historique intacte, évite à un patrouilleur de perdre du temps, décourage le vandale (là encore Salebot n'agit qu'après coup),
• Salebot restera en place. Il continuera de tourner parce qu'il a aussi ses propres avantages : il n'analyse pas que la modification, il analyse aussi les interactions entre les contributeurs, ce que ne fera pas AbuseFilter. En ce sens Salebot est « intelligent », il est par exemple capable de modifier son comportement si un contributeur intervient dans l'historique d'un article entre deux modifs. Salebot a de toute façon une grande longueur d'avance : il fonctionne depuis plus de deux ans et ses algorithmes sont très développés, il continuera de révoquer des choses même si son activité devrait diminuer sensiblement une fois les principaux filtres de AbuseFilter mis en place.
  D'autre part Gribeco (le dresseur de Salebot) me disait hier qu'il attendait avec impatience la mise en place de AbuseFilter et de son système de balisage pour justement que Salebot lise ces balises dans les RC pour améliorer ses propres algorithmes et son efficacité ; Gribeco a l'air d'attendre une synergie Salebot/AbuseFilter (voir avec lui plus de détails).
• utilisateur:Salebot est un compte utilisateur classique, mais dont les actions sont automatisées. AbuseFilter est une extension de logiciel intégrée à MediaWiki. Par principe les développeurs ne mettent pas en place une extension sur un site sans s'être assuré que la communauté locale donne son feu vert. D'autre part il y a de options et paramètres à choisir et les développeurs ne peuvent pas le faire à notre place. Pour ces deux raisons il faut une prise de décision. Mais il ne s'agit pas d'un problème de « dangers ». Pour te rassurer sur ce dernier point : plus de 20 Wikipédias (dont toutes les plus grandes, en:, de:, pl: etc.) ont déjà mis AbuseFilter en place courant 2009 (et à ce titre nous n'auront pas à essuyer les plâtres).

Kropotkine_113 24 janvier 2010 à 23:07 (CET)

(Lu et approuvé -- je suis tout-à-fait favorable à AbuseFilter. --Gribeco (d) 24 janvier 2010 à 23:20 (CET))

J'ajouterai un avantage considérable (quoique paradoxal) de Salebot : on peut le reverter s'il se trompe, ce qui n'est malheureusement pas encore le cas avec AbuseFilter. Ce qui ne veut surtout pas dire que les filtres abusefilter feront des erreurs qu'on ne pourra pas annuler ; c'est juste qu'ils ne pourront pas être aussi entreprenants pour bloquer des éditions que Salebot peut se permettre de l'être pour les reverter. — Arkanosis ^✉ 25 janvier 2010 à 11:04 (CET)

AbuseFilter a un journal qui liste toutes les modifications qui déclenchent un filtre (même si ça ne déclenche pas d'action du filtre), on pourra donc vérifier qu'il n'y a pas d'erreur. En plus je pense qu'on créera une page pour signaler les faux positifs (et qu'on l'indiquera dans les messages avertissant d'une interdiction de publication ). Moyg hop 25 janvier 2010 à 11:15 (CET)

Oui il y aura évidemment une page de faux positifs mise en avant pour chaque déclenchement de filtre et au début la lecture intensive du journal sera une bonne occupation pour les codeurs de filtres Dans tous les cas, il faudra être très précautionneux au départ et n'utiliser la fonction « interdire » que pour des cas triviaux où le risque de faux positifs est quasi nul. Le gros avantage qu'on a par rapport à d'autres wiki, c'est justement qu'on a aussi Salebot et qu'il pourra toujours continuer à faire tout ce qui est un peu difficile/dangereux à mettre dans un filtre d'interdiction ; un des gains espérés est que grâce à Abusefilter et notamment à ses messages d'avertissements et d'aide, Salebot ait beaucoup moins de boulot sans que les filtres n'interdisent brutalement les modifs. Bref il y a une synergie prévention (Abusefilter)/répression (Salebot) qui peut aussi être très intéressante à mettre en place. Kropotkine_113 25 janvier 2010 à 11:44 (CET)

@Moyg: oui, on peut vérifier qu'il n'y a pas d'erreur, mais s'il y en a une on ne peut pas l'annuler d'un simple clic . Pour ça, il faudra patcher abusefilter (et LiveRC, tant qu'à faire : c'est encore ce que l'on a de mieux pour être réactif en cas d'erreur). — Arkanosis ^✉ 25 janvier 2010 à 13:54 (CET)

Je m'élève avec vigueur

... contre la longueur de cette page. Alerté par le Bistro, je viens ici avec l'intention louable (en théorie) de m'informer, de tenter de comprendre et de voter pour participer et faire vivre. Je tombe sur des dizaines de milliers de signes. Où est la concision ? Ah d'accord, c'est rouge, je comprends mieux. Si ce qui se conçoit bien s'énonce clairement, ce qui se conçoit vraiment bien s'énonce brièvement - parlez-en à Abraham.--Environnement2100 (d) 25 janvier 2010 à 00:19 (CET)

Je ne connais pas user:Abraham mais j'aurais accepté avec beaucoup de plaisir son aide pour la rédaction de la page. Plus sérieusement : désolé, j'ai fait ce que j'ai pu pour simplifier. Il y a aussi Aide:AbuseFilter pour vois aider, mais j'ai peur que sa longueur ne vous rebute. Kropotkine_113 25 janvier 2010 à 00:34 (CET)

Décompte provisoire des votes au 26 janvier 2010 à 19 h 52

Retiré suite à la discussion ci-dessous (toujours dans l'historique si ça vous intéresse).

C'est pas un peu tôt pour dresser un décompte, après seulement deux jours de vote sur un mois ? Cordialement, Freewol (d) 27 janvier 2010 à 09:44 (CET)

Je trouve d'ailleurs depuis toujours ce système de décompte des votes irrespectueux des votants potentiels. Il est notamment utilisé dans les élection sau comité d'arbitrage et, en fait, il pourrait servir, en théorie, à chercher à influencer ceux qui n'ont pas encore voté, en faisant apparaître une tendance, etc. Ceux que les tendances d'un vote public intéressent ont tout à fait la ressource de compter eux-mêmes les suffrages. Dans un autre domaine, lorsque l'on élit les membres soumis à élection du conseil d'administration — ' — de Wikimedia Foundation, Inc., le scrutin est totalement secret, et personne ne peut, par la force des choses, publier ces fameuses « tendances ». Hégésippe | ±Θ± 27 janvier 2010 à 10:32 (CET)

Ce n'était pas du tout l'intention : l'objectif était de faciliter la lecture du vote de Condorcet (la lecture des votes majoritaires à scrutin public étant, par nature, accessible à tous).

Mais soit, le décompte n'est sans doute pas indispensable à ce stade, je le retire.

Amicalement — Arkanosis ^✉ 27 janvier 2010 à 10:46 (CET)

avis perso : soit le vote est secret et il n'y a pas de décompte avant la clôture (mais un risque de suspicion puisque chacun ne peut voir ce qu'il a voté, donc il faut un dépouillement vérifiable), soit il est public et de toutes manières, tout le monde peut faire le décompte, le commenter etc... personnellement je trouve que le vote public est la solution la plus conforme à l'esprit de transparence de wikipédia, donc la "moins mauvaise". Je ne vois pas d'irrespect dans le fait de faire une synthèse d'informations qui sont publiques --Ofol ^{(moi . ✍)} 27 janvier 2010 à 10:51 (CET)

Mais quel en est l'intérêt et la nécessité ? Les votants sont assez grands, je pense, pour se décider sans avoir besoin de consulter un récapitulatif, réactualisé régulièrement, des tendances qui se manifestent durant le vote. Quant au décompte final, eh bien en toute logique il doit se faire à la fin, sans qu'il soit utile de faire des décomptes intermédiaires... Hégésippe | ±Θ± 27 janvier 2010 à 12:02 (CET)

de l'intérêt et de la nécessité, à mon avis, le lecteur doit être le seul juge. Personnellement j'aime bien revenir de temps en temps sur une décision, lire les avis et compter les votes.. mais avec un Condorcet difficile de s'y retrouver donc la synthèse d'Arkanosis ne m'est pas inutile --Ofol ^{(moi . ✍)} 28 janvier 2010 à 21:59 (CET)

Statuts

Comme je l'ai indiqué sur la page du vote, je pense qu'il serait judicieux que les droits suivants soient accordés :

• Pour les utilisateurs "abusefilters" :
  • Droit de créer, modifier et supprimer des filtres ;
  • Droit de supprimer des filtres ;
  • Droit de suspendre un filtre problématique ;
  • Droit de révoquer une action erronée effectuée par un filtre ;
  • Droit de confirmer un filtrage effectué.
• Pour les administrateurs :
  • Droit de suspendre un filtre problématique ;
  • Droit de révoquer une action erronée effectuée par un filtre.
• Pour les utilisateurs autoconfirmed :
  • Droit de révoquer une action erronée effectuée par un filtre ;
  • Droit de confirmer un filtrage effectué.

Qu'en pensez-vous ? —————— Pic-Sou, le lundi 1 février 2010 à 18:30 (UTC)

J'en pense que ce n'est tout simplement pas possible. Déjà il n'y a pas de fonctionnalité « confirmer un filtrage effectué ». Pour la fonction « révoquer » cf plus haut. Ensuite il n'est pas prévu par l'extension d'attribuer un même droit à deux groupes distincts donc le recouvrement que tu proposes entre abusefilter et admin n'est pas possible partiellement : soit les admins ont tous ces droits, soit les abusefilter les ont tous et pas les admins ; en revanche il est possible d'être admin et abusefilter. Mais ce que tu proposes n'est tout simplement pas prévu par le logiciel. Kropotkine_113 1 février 2010 à 19:39 (CET)

De mémoire on peut saupoudrer les droits sur différents groupes avec ou sans recouvrement (c'est les sysadm qui le font directement dans le fichier de conf de mediawiki). Sur le reste je confirme (bien malheureusement pour la révocation). — Arkanosis ^✉ 1 février 2010 à 20:36 (CET)

$wgGroupPermissions['abusefilter']['abusefilter-modify'] = true;
$wgGroupPermissions['sysop']['abusefilter-log-detail'] = true;
$wgGroupPermissions['*']['abusefilter-view'] = true;
//...

En ce qui concerne les droits évoqués par Pic-sou, créer/modifier/supprimer/suspendre un filtre, ils sont tous contenus dans abusefilter-modify et ne peuvent donc pas être attribués à deux groupes distincts ou ventilés subtilement. Kropotkine_113 1 février 2010 à 20:42 (CET)

OK, excusez-moi... —————— Pic-Sou, le mardi 2 février 2010 à 17:25 (UTC)

Décision grave, mais informations très insuffisantes : critères d'interdiction de publication

J'attire l'attention des votants sur le fait de se prononcer sur l'activation par défaut d'un système pouvant interdire une contribution (la PdD indique : « En dehors des points mis aux votes dans la présente prise de décision, les options choisies seraient les suivantes : […] interdiction ») sans connaître les modalités de cette interdiction. À mon sens ces modalités doivent être décidées en même temps que l'activation ou non de cette fonctionnalité : personnellement mon vote dépend des critères choisis pour l'interdiction, et je ne peux me prononcer sans les connaître. En particulier, le fait que cette interdiction puisse se faire par rapport à certains mots serait pour moi un véto. Skippy le Grand Gourou (d) 11 février 2010 à 18:10 (CET)

Tout d'abord, il ne s'agit pas d'une activation par défaut puisqu'on demande l'avis de la communauté pour savoir si elle est d'accord. Les options importantes sont parfaitement explicitées, si on ne veut pas de l'option « interdire » il est tout à fait possible de voter contre cette prise de décision. Ensuite, on a affaire ici à une prise de décision technique (destinée aux développeurs) pour savoir si on veut avoir un outil technique en plus. La façon dont on se servira de cet outil est à décider par la communauté, qui aura toujours le dernier mot, comme pour toutes les règles de fonctionnement de Wikipédia. Tout le monde pourra s'exprimer s'il juge un filtre mal conçu ou une interdiction de modification abusive ; toutes les actions seront journalisées, et la définition des filtres visibles par le plus grand nombre de contributeurs. Tout le monde pourra aussi lancer une prise de décisions pour interdire les interdictions etc.

Sur le fond du problème (que je comprends très bien) : il est quasiment impossible de définir des « modalités d'interdiction » ou « des critères » a priori valables pour toutes les situations et pour tous les filtres imaginables. Les cas de figures sont très nombreux et très variés et le filtrage d'un texte à partir d'expressions régulières est un art très délicat. Et en plus il faut voir les filtres en situation réelle avant de pouvoir évaluer quoi que ce soit. Pour dédramatiser, il faut bien voir aussi qu'il s'agit d'un système très souple pour lequel on peut toujours tout modifier tout le temps : on peut imaginer un filtre pour lequel une interdiction paraît pertinente et puis s'apercevoir à l'usage qu'interdire n'est pas la bonne solution ou que les faux positifs sont trop nombreux, donc supprimer l'interdiction. Ou le contraire. Rien n'est figé et si on se trompe on peut toujours corriger rapidement etc. Tout ça sera à évaluer une fois qu'on aura commencé à installer des premiers filtres, qu'on aura des retours statistiques concrets etc. Et ton avis sera alors le bienvenu pour éviter tout travers que tu jugerais inacceptable.

Mon opinion personnelle (partagées par d'autres personnes, si tu lis cette page de discussion en entier) : l'interdiction de modifications devrait toujours rester l'exception, restreinte aux vandalismes grossiers et évidents pour lesquels les faux positifs sont quasi nuls. C'est ce que je constate de ce qui se passe sur en:, par exemple.

Pour terminer sur la fin de ton message, un filtre peut très bien interdire « va niquer ta mère fils de pute », ce qui est stricto sensu une interdiction qui se fait « par rapport à certains mots ». Si tu estimes que cela est trop dangereux, tu peux voter contre. (En revanche il n'y a pas de véto prévu.)

Kropotkine_113 11 février 2010 à 18:53 (CET)

Avant toute chose, je précise afin qu'il n'y ai pas de malentendu que d'une part le véto s'entendait comme un véto personnel (sur ma décision) et non comme un véto au sein du vote, et que d'autre part par « par défaut » (/paʁ/³, ah quel poète je fais… ) je souhaitais simplement souligner que le vote ne portait pas sur l'activation ou non de cette option, qui fait partie du « pack ».

L'interdiction d'une contribution n'est pas anodine, et quand je vois la frilosité de mon entourage à faire la moindre modif, la moindre erreur concernant cette fonctionnalité serait à mon sens dramatique.

Pour faire bref, je préférerais que cette option ne soit pas considérée dans la présente prise de décision, et qu'on revienne dessus si la mise en place d'AbuseFilter est votée. Ce qui, en pratique, revient à supprimer la première occurrence du mot « interdiction » dans la phrase « les actions possibles sont : journalisation, marquage (balisage), avertissement, seuil de déclenchement (throttling), interdiction, interdiction de l'accès automatique à un statut ». Skippy le Grand Gourou (d) 11 février 2010 à 19:48 (CET)

Le texte de la prise de décision est parfaitement clair et la page d'aide détaille précisément les actions des filtres. Je pense que les 81 personnes ayant voté à l'heure pour la mise en place d'abusefilter l'ont fait en connaissance de cause ; dans le cas contraire elles peuvent changer d'avis. Tu n'es pas le premier à soulever, à juste titre, le caractère sensible des interdictions de modifications. Changer le texte après plus de deux semaines de vote est une mauvaise idée quand ce texte fait quasiment consensus. Il reste tout à fait possible de supprimer l'action « interdire » par la suite si la communauté la trouve dangereuse et/ou mauvaise, ou de décider de règles contraignantes pour que cette action puisse être envisagée par un filtre. Mais je le répète, quoi qu'il arrive c'est à la communauté de décider de ce qu'on va faire de ces filtres, personne ne sera dépossédé de la possibilité de donner son avis sur chaque filtre une fois que le système sera mis en place. Kropotkine_113 12 février 2010 à 10:05 (CET)

Captures d'écran

Outre le point précédent, j'aurais apprécié que soient présentés des aperçus de cette extension en action, à savoir ce que verrait le contributeur qui déclencherait un filtre. Une recherche très rapide me donne cette image, valable dans le cas d'un blanchiment. Est-il possible d'obtenir d'autres exemples ? Merci. Skippy le Grand Gourou (d) 11 février 2010 à 18:10 (CET)

Le système n'est pas encore activé sur fr: : on ne peut donc tout simplement pas te montrer d'exemples en action. Si abusefilter est installé il faudra créer localement les messages d'avertissement. On fait ce qu'on veut avec les messages d'avertissement, ils ne sont pas livrés avec l'extension, donc on pourra tout modifier et discuter ici entre nous. Pour voir d'autres exemples de messages utilisés sur en: c'est par là. Dans la page d'aide j'ai aussi donné les liens vers en: pour voir ce qu'est le journal, le journal détaillé etc. Kropotkine_113 11 février 2010 à 18:24 (CET)

Merci, ton lien vers les exemples en anglais m'est amplement suffisant pour me faire une idée. Skippy le Grand Gourou (d) 11 février 2010 à 18:33 (CET)

Et l'orthographe ?

Est-il possible d'implémenter comme filtre un détecteur de fautes d'orthographe, qui avertirait le contributeur que certains mots sont mal orthographiés, l'obligeant à se relire avant de valider sa contribution ? Skippy le Grand Gourou (d) 11 février 2010 à 18:10 (CET)

Oui, c'est possible en théorie mais en réalité il est très difficile de créer un filtre pertinent en ce qui concerne l'orthographe. Il risque donc d'y avoir beaucoup de faux positifs et d'avertissements indus, ce qui nuit à l'efficacité du système et surtout décrédibilise Wikipédia (avertir d'une faute d'orthographe imaginaire c'est pas glorieux). Donc pourquoi pas, je pense qu'on peut toujours trouver quelques situations où cela va marcher, mais on risque de ne pas filtrer grand chose. Kropotkine_113 11 février 2010 à 18:28 (CET)

Pour l'instant c'est juste une idée comme ça, sur le principe. Je pense qu'il n'est pas si difficile de créer un filtre pertinent, du moment qu'il est lâche : mots sans majuscule absent d'un dictionnaire (à condition que le dictionnaire soit suffisamment complet, évidemment), erreurs fréquentes (par expressions : exemple bidon pris au hasard (il faudrait faire une étude de la fréquence des erreurs pour trouver les plus pertinentes), « les meme »). Après il faut voir si ça ne serait pas trop gourmand en ressources, peut-être permettre aux contributeurs confirmés de l'activer, etc. Je tâte juste le terrain. Skippy le Grand Gourou (d) 11 février 2010 à 18:42 (CET)

Moi je ne suis pas très fort en code, mais tout ce que j'entends de la part de gens qui le sont c'est que l'orthographe c'est pas facile à gérer : trop de nuances, trop de subtilités. C'est pour ça notamment que les bots sont a priori interdits de modifications orthographiques massives et qu'on laisse cette tâche à des humains. Mais si une idée marche de ce point de vue on pourra bien sûr l'essayer, pour voir. Kropotkine_113 11 février 2010 à 18:57 (CET)

Difficile pour les mots absents du dictionnaire (tu n’auras jamais un dico assez grand), particulièrement pour les histoires de titres d’œuvres étrangers (non, tout le monde ne sait pas qu’il faut les mettre en italique, donc non, tu ne peux pas te baser là-dessus…). Par contre, la signalisation de petites fautes de français doit être gérable (certains bots le font déjà). Nemoi s’est exprimé ici le 15 février 2010 à 19:37 (CET)

Droits de modifications des filtres

Bonjour. Le résultat de la consultation concernant les droits de modifications des filtres est très serrée. Les votes sont scindés en deux sections « groupe administrateur » et « groupe abusefilter » avec, pour ce dernier groupe, une sous-section « groupe abusefilter + administrateur ». L'ensemble des votes de la section « abusefilter » sera selon toute vraisemblance majoritaire mais quelle que soit le façon de compter les positions sont très équilibrées.

Je propose donc un compromis qui j'espère emportera l'adhésion du plus grand nombre et se rapprochera donc du consensus. Je propose aussi, suite aux discussions tenues plus haut sur cette page, des modalités d'accession au groupe abusefilter pour tous les autres utilisateurs, l'objectif étant d'être souple, simple, sans procédure compliquée et surtout de permettre à toutes les compétences d'être utilisées.

Je propose donc les modalités suivantes d'application de la prise de décision, l'objectif étant d'être souple, simple, sans procédure compliquée et surtout de permettre à toutes les compétences d'être utilisées.

« Les droits de modification et de création des filtres sont attribués au groupe dédié abusefilter. De plus : tous les administrateurs qui en font la demande aux bureaucrates ont accès à ce groupe ; les contributeurs souhaitant accéder à ce groupe en font une demande sur Wikipédia:AbuseFilter/Demande des droits de modification. Ils motivent et argumentent leur demande. Un délai de [une semaine / quinze jours] est instauré pour permettre à n'importe quel contributeur autopatrolled de s'opposer à cette demande. Si personne ne s'oppose à cette accession dans ce délai, la demande d'accession est transmise aux bureaucrates qui donnent le statut au demandeur. Si une personne s'oppose à l'accession, il s'ensuit une discussion entre le demandeur et son opposant pour éventuellement lever les obstacles ; si l'opposition persiste au bout d'une semaine, la demande est rejetée. »

Qu'est-ce que vous en pensez ? Si on suit l'exemple de l'attribution du statut de bot on peut réduire le délai à une semaine par exemple.

Kropotkine_113 24 février 2010 à 16:53 (CET)

Ça me va.

Pour la durée de la consultation, je verrais plutôt 7 jours, qui sont amplement suffisants à mon avis pour que tout le monde ait le temps de formuler une opposition contre un quelconque aspirant à ce statut (qui est nettement moins important que le statut d'administrateur).

Elfix ↗^discuter. 24 février 2010 à 17:11 (CET)

Idem. 7 jours ou 15 jours... ma foi... il n'y a à priori pas d'urgence à faire partie du groupe et la possibilité d'interdire une édition avec un filtre (à éviter, mais la possibilité est bien là), fait qu'il reste malgré tout important que les oppositions puissent se manifester. — Arkanosis ^✉ 24 février 2010 à 17:20 (CET)

J'approuve les modalités proposées, mais je ne partage pas l'idée de compromis et je trouve que ça va un peu vite. Il n'y a pas pour le moment de problème même petit : il faut tirer les conclusions basiques de la PDD selon les conditions prévues. Une fois cela fait, on discute de la constitution du groupe AbuseFilter puisque c'est lui qui est retenu même de peu. Le compromis dont tu parles disparaît derrière ces question de modalités ; il suffit effectivement de prévoir le cas des administrateurs et on n'a jamais dit qu'il n'y aurait pas « un cas des administrateurs ». (Et donc là je redis que je les approuve, ces modalités). Bref, je suis d'accord pour la suite, mais je ne vois pas ici et maintenant la pertinence de cet encadré rouge : on a pas à interpréter la PDD et à proposer autre chose - et si tu veux dès maintenant - que de discuter du nouveau groupe en repartant à zéro. TigHervé (d) 24 février 2010 à 20:04 (CET)

Oui moi aussi je suis assez d'accord pour avoir une lecture simple du résultat de la prise de décision : on compte les voix, on applique et après on avise ; le groupe abusefilter va très certainement sortir majoritaire : dont acte, c'est lui qui aura les droits dans la configuration de l'extension. Je ne discute pas de ça. Peut-être que « compromis » est un terme mal choisi ; ce que je cherche c'est anticiper sur la suite en recherchant le consensus le plus grand possible : trouver une modalité de construction de ce groupe abusefilter qui permette de prendre en compte les grosso modo 45% de votes pour « administrateur ». Le cadre rouge n'est pas là pour signifier quoi que ce soit en terme d'interprétation de la pdd, mais juste pour donner de la visibilité au petit texte que je propose qui se veut une étape après le dépouillement des votes et la conclusion de cette pdd Kropotkine_113 24 février 2010 à 20:22 (CET)

Ouf ! :) je craignais vaguement que tu copies-colles ça comme conclusion quelque part. Il y a des pointilleux qui n'auraient peut-être pas aimé. (Je relis -> de toute façon, tu ne peux pas prendre en compte les 45% de votes administrateurs, ils ont voté contre l'autre, c'est tout.)

Une fois rassuré, je me demande quand même s'il ne serait pas mieux d'avoir une seule page de demande quitte à sonner chez les bubus si un admin est vraiment impatient. Est-ce que l'entête de la page (unique) de demande ne suffirait pas à préciser aux demandeurs selon qu'ils sont administrateurs ou pas ce qu'ils doivent faire/justifier dans la page ? On a une seule page obligée pour tous et moins le sentiment d'un privilège et raccourci des admins ? Bon, faut voir... TigHervé (d) 24 février 2010 à 20:34 (CET)

(Rem : je prends connaissance à l’instant des propos entre Kropot et TigHervé, ayant écrit ceci sans connexion : tout à fait d’accord avec vous 2 pour prendre un peu de temps pour dépouiller les votes (ce que j’évoque ici) avant d’aller plus loin … ce qui est l’objet de ce petit apport.)

<petite intervention en passant (d'autant que je suis peu disponible actuellement) de quelqu'un qui ne s'est pas impliqué dans cette prise de décision ; donc si c'est à côté de la plaque, oubliez ;-) >

Bonjour, donc le vote concernant qui peut créer/modifier les flitres donne 39 : abuse Filter ; 9 : Abuser Filter + Admin ; 39 : Admin seulement. Il est en effet serré mais donne me semble t-il 2 résultats : 1. les admin peuvent créer/modifier 2. des non-admin peuvent aussi créer /modifier s'il sont admis comme Abuse Filter ; "statut" qui est donc créé.

Là on entre alors sur la question que tout le monde attend : comment devient-on abuse filter ? Là je crois qu'un nouveau vote prenant pour acquis le vote précédant (si quelqu'un a le temps, l'envie et l'énergie d'en faire le bilan ...) peut être utile. Nouveau vote plus rapide que le précèdent : une semaine, 15 jours ?

Pour être productif je suggèrerais, pour compléter la proposition de Kropotkine_113, les questions suivantes en vote (ce qui n'est pas souligné est du commentaire) :

1. Un abuse filter non admin doit-il être déjà lui-même autopatrolled ? (oui, non, neutre) : ceci est précisé car si 39 personnes (sur 39+39+9) jugent que seuls les admin peuvent avoir le statut, possiblement une majorité est contre que le statut puisse être donné à une personne de moins de 90 jours ou 500 édits. A ma connaissance, suite à des modifs un peu rapides de nouveaux trop enthousiastes, on a limité la possibilité d'utiliser LiveRC pour le restreindre aux seuls autopatrolled.
2. (question indépendante) Comment s'opère l'acquisition du statut ? 1. Simple demande sans opposition d'un autopatrolled. (comme suggéré par Kropot., ce qui me semble bon car plus restrictif que : ) 2. Simple demande sans opposition d'un admin + abuse Filter ?
   1. (sous question de la précédente mais elle aussi indépendante) Qui tranche ? 1. la majorité simple du vote ci-dessus (me semple simplifier tout) 2. les Bureaucrates

Voilou, si j'ai pu aider ... --Epsilon0 ε₀ 24 février 2010 à 21:25 (CET)

Alors dans l'ordre :

• les résultats : ils ne sont pas durs à dépouiller ; (à l'heure où j'écris) abusefilter = 39+9 = 48 ; administrateur = 39. Il n'y a que deux choix soumis aux votes, la sous-section abusefilter+administrateur devant être interprétée comme un commentaire de vote ; le groupe qui aura les droits sera donc selon toute vraisemblance le groupe abusefilter ;
• si on pouvait éviter un vote en ce qui concerne les modalités d'application de la prise de décisions ce serait aussi bien. On avait besoin d'un vote un peu formalisé pour que les développeurs mettent en place l'extension, mais pour les modalités d'application on peut s'en sortir par la discussion (c'est-à-dire ce qu'on est en train d faire en ce moment) ;
• le candidat doit-il être autoconfirmed ? : l'intérêt d'une procédure où le candidat demande et obtient le statut sauf opposition c'est que, justement on ne vote pas, et qu'il n'est pas nécessaire d'imposer de critère restrictif aux dépôts de candidatures puisque si le candidat est jugé trop vert il obtiendra à coup sûr une opposition ; on peut rajouter cette restriction mais dans les faits elle ne servira à rien ;
• qui tranche ? : dans le cas d'une admission sauf opposition il y a deux cas : 1) si pas d'opposition, personne n'a a trancher quoi que ce soit, les bureaucrates donnent le statut et c'est tout 2) s'il y a opposition on peut peut-être rajouter un vote ce qui permettrait d'éviter les oppositions systématiques pouvant bloquer la procédure et qui donnerait, en gros, la chose suivante (alternative en ce qui concerne les non-admins, suggérée par Nemoi) :
  « […] Si une personne s'oppose à l'accession, il s'ensuit une discussion entre le demandeur et son opposant pour éventuellement lever les obstacles ; si l'opposition persiste au bout d'une semaine, la demande est rejetée soumise à un vote d'une semaine et acceptée si [conditions de vote + % à définir]. »

Kropotkine_113 24 février 2010 à 21:56 (CET)

@Epsilon0 - je crois qu'on part sur trop de formalisme, de procédures et d'inconnues-suppositions et je crois qu'il faut au contraire faire preuve de pragmatisme et s'occuper d'une mise en place progressive et adaptative ; les choses étant bien différentes quand on aura de l'expérience, expérience de gestion de ces questions (et des filtres) et expérience des premiers membres AbuseFilter. Je ne serais donc pas contre des critères restrictifs le temps que cette expérience se fasse et ensuite un abaissement en plusieurs temps desdites exigences. On saurait ainsi les problèmes précisément posés et par exemple si des votes ont de la pertinence par rapport à la discussion. Moi je ne vois pas les conditions d'accès figées avant plusieurs semaines. TigHervé (d) 24 février 2010 à 22:56 (CET)

Ok, en effet ce que je proposais était p.-e. trop procédurier, si cela peut se faire plus simplement très bien. Aussi je n'avais pas compris que seuls les bureaucrates pouvaient attribuer ce statut comme il en est pour celui d'admin et via étais étonné qu'ils interviennent sur cette question. --Epsilon0 ε₀ 25 février 2010 à 17:57 (CET)

Juste en passant, je ne suis pas sûr que l'interprétation des résultats consistant à inclure les 9 votes « abusefilter + admins » dans les votes « abusefilter » soit correcte : il y a au moins un de ces votes (celui d'HelloWorld) qui exprime explicitement le contraire, Udufruduhu s'est exprimé pour les admins seulement avant de modifier son vote, et le vote d'O.Morand me semble (mais j'interprète peut-être abusivement) aller également dans ce sens. Skippy le Grand Gourou (d) 24 février 2010 à 23:31 (CET)

Il s'agit d'une sous-section de vote incluse dans la section « abusefilter » ; le texte de la prise de décision a toujours stipulé « Vote à la majorité simple. Il n'y a que deux choix possibles : groupe abusefilter ou administrateurs. » Et Nemoi quand il a créé la sous-section a clairement indiqué : « Comme je l’ai dit sur IRC, j’ai été gentil de mettre ce groupe en sous-groupe d’abusefilter, sans quoi en effet le vote se trouvait contestable. » donc je pense que les gens ont voté en connaissance de cause. Notons que l'attribution du droit au groupe abusefilter n'est absolument pas incompatible avec les votes que tu cites, il s'agit juste d'une modalité particulière d'application où les admins sont dans ce groupe s'ils le demandent (et c'est dans l'esprit ce que je propose plus haut). Kropotkine_113 24 février 2010 à 23:52 (CET)

Oui, j'ai vu (aujourd'hui) que c'était une sous-section, mais ça n'est pas évident au premier abord et je n'ai pas l'impression que tous les votants l'aient considéré. Je cite le vote d'HelloWorld : « "AbuseFilter avec Administrateur" > " Administrateur" > " AbuseFilter " », ça me semble clair. Skippy le Grand Gourou (d) 25 février 2010 à 00:21 (CET)

Pragmatisme oui. Critères restrictifs bof, pourquoi pas, mais ça me parait inutile. Étant donné qu'une grande partie des votants a exprimé le sentiment qu'il fallait au minimum être administrateur pour modifier un filtre, et que d'autres ont manifesté leur frilosité vis à vis d'une extension qui leur apparait comme sensible, je crois qu'il n'y a aucune chance pour un utilisateur inexpérimenté et sans projet argumenté de se voir attribuer les droits de modification. Pas besoin d'une procédure complexe. Il n'y a guère que quelques administrateurs inspirant confiance et/ou ayant de l'expérience dans le dressage de bots qui ne se verront pas opposer un refus catégorique. Avec l'expérience de ces quelques pionniers et les retours de la communauté en général il sera plus facile, par la suite, et seulement si le besoin se fait sentir, de mettre en place des procédures ou des limitations qui soient réellement adaptées à des problèmes que nous rencontrerons concrètement, mais que nous ne pouvons pour l'instant qu'imaginer.Pachycephale (d) 24 février 2010 à 23:59 (CET)

Oui - tu dis mieux que moi ce que je voulais dire :) ; à ceci près cependant qu'il ne faut pas seulement s'occuper de former le groupe, il faut aussi s'occuper d'éviter le maximum de discussions inutiles, malentendus, contestations, etc. C'est pour moi aussi important, dans le cas d'une fonction dont on se passait jusqu'à présent.

Par ailleurs, je suis encore davantage pour étaler temporellement la mise en oeuvre. Je pense à la qualité des pages qui vont servir aux pionniers de la fonction ou aux procédures ou pages prévues pour encadrer ou réparer des dégats directs ou collatéraux. Tiens ne faudrait-il pas un projet, même pour quelques mois, rien que pour la mise en place ; cela éviterait de polluer d'autres pages comme WP:RA ou le Bistro.

Pour revenir à la question des pionniers. Peut-on faire un appel aux volontaires administrateurs codeurs de filtre (en limitant à une dizaine si besoin est) pour essuyer les plâtres pendant deux mois par exemple ? On ferait un bilan et on ouvrirait le groupe. ??? TigHervé (d) 25 février 2010 à 08:14 (CET)

Décompte des votes au 25 février 2010 à 11 h 5

Installation de l'extension

Installation de l'extension (102 votes)
Oui : 91	89 %
Non : 8	8 %
Neutre : 3	3 %
Oui / (Oui + Non)	92 %

Droits des utilisateurs selon le groupe

A - Droit de créer ou modifier des filtres

A - Droit de créer ou modifier des filtres (88 votes)
Groupe abusefilter : 39	44 %
Groupe abusefilter dont les administrateurs : 8	9 %
Total groupe abusefilter : 47	53 %
Administrateurs : 41	47 %

B - Droit de voir le code-source de tout filtre paramétré comme public

B - Droit de voir le code-source de tout filtre paramétré comme public (90 votes)
Tous les utilisateurs : 42	47 %
Groupe autoconfirmed : 48	53 %

C - Droit de voir le détail de chaque entrée du journal

Votes normalisés (90 votes)

• 2 > 3 > 1 > Z | Gribeco
• 2 > 3 > 1 > Z | Hégésippe Cormier
• 1 > 2 > 3 > Z | Kropotkine 113
• 2 > 3 > 1 > Z | Kyro
• 2 > 3 > 1 > Z | Ofol
• 2 > 3 > 1 > Z | Alphos
• 2 > 3 > 1 > Z | Clem23
• 2 > 3 > 1 > Z | Nakor
• 1 > 2 > 3 > Z | Noritaka666
• 2 > 3 > 1 > Z | Rhadamante
• 2 > 3 > 1 > Z | Okki
• 2 > 3 > 1 > Z | Gemini1980
• 1 > 2 > 3 > Z | Dodoïste
• 2 > 1 > 3 > Z | Nemoi
• 1 > 2 > 3 > Z | Gz260
• 2 > 3 > 1 > Z | Bloody-libu
• 2 > 3 > 1 > Z | Cantons-de-l'Est
• 2 > 3 > 1 > Z | Tpt
• 2 > 1 > 3 > Z | Manoillon
• 2 > 3 > 1 > Z | Égoïté
• 2 > 3 > 1 > Z | Jejecam
• 3 > 2 > 1 > Z | Stef48
• 2 > 3 > 1 > Z | Croquant
• 1 > 2 > 3 > Z | Nouill
• 2 > 3 > 1 > Z | Bokken
• 2 > 3 > 1 > Z | Freewol
• 2 > 3 > 1 > Z | Chandres
• 2 > 3 > 1 > Z | Sardur
• 2 > 3 > 1 > Z | Leag
• 2 > 3 > 1 > Z | Moyg
• 2 > 3 > 1 > Z | DocteurCosmos
• 1 > 2 > 3 > Z | Arkanosis
• 2 > 3 > 1 > Z | Rosier
• 1 > 2 > 3 > Z | Herr Satz
• 1 > 2 > 3 > Z | loreleil
• 2 > 1 > 3 > Z | Dreoven
• 1 > 2 > 3 > Z | Ludo29
• 2 > 3 > 1 > Z | ohkami
• 3 > 2 > 1 > Z | ILJR
• 1 > 2 = 3 = Z | Sebjarod
• 2 > 3 > 1 > Z | D4m1en
• 2 > 1 > 3 > Z | Wikinade
• 2 > 3 > 1 > Z | Padawane
• 1 = 2 > 3 > Z | Elfix
• 2 > 1 > 3 > Z | Sylenius
• 2 > 3 > 1 > Z | Coyau
• 1 > 2 > 3 > Z | Esprit Fugace
• 2 > 3 > 1 > Z | Akeron
• 2 > 3 > 1 > Z | Bapti
• 2 > 3 > 1 > Z | TigH
• 1 > 2 > 3 > Z | Pachycephale
• 1 > 2 > 3 > Z | Tejgad
• 2 > 1 > 3 > Z | LPLT
• 2 > 1 > 3 > Z | Voxhominis
• 2 > 3 > 1 > Z | Adrille
• 2 > 3 > 1 > Z | Vyk
• 2 > 3 > 1 > Z | Udufruduhu
• 2 > 1 > 3 > Z | Hellotheworld
• 2 > 3 > 1 > Z | Jean-Christophe BENOIST
• 2 > 3 > 1 > Z | Ampon
• 2 > 1 = 3 = Z | Kolossus
• 2 > 3 > 1 > Z | Moipaulochon
• 2 > 3 > 1 > Z | Darkoneko
• 2 > 3 > 1 > Z | Snipre
• 1 > 2 > 3 > Z | Quéré
• 2 > 3 > 1 > Z | Quoique
• 2 > 3 > 1 > Z | Litlok
• 2 > 3 > 1 > Z | Thesupermat
• 2 > 3 > 1 > Z | Buisson38
• 2 > 1 > 3 > Z | Deep silence
• 2 > 3 > 1 > Z | David Berardan
• 2 > 1 > 3 > Z | Aroche
• 2 > 3 > 1 > Z | Zivax
• 2 > 1 > 3 > Z | Mirgolth
• 1 > 2 > 3 > Z | Pic-Sou
• 1 > 2 > 3 > Z | Manu1400
• 2 > 3 > 1 > Z | En passant
• 1 > 2 > 3 > Z | Tonymainaki
• 1 > 2 > 3 > Z | Hegor
• 3 > 2 > 1 > Z | O. Morand
• 1 > 2 > 3 > Z | Epsilon0
• 1 > 2 > 3 > Z | Drongou
• 1 > 2 > 3 > Z | Schutz
• 1 > 2 > 3 > Z | Nutsy
• 2 > 3 > 1 > Z | Xic667
• 1 > 2 > 3 > Z | Skippy le Grand Gourou
• 1 > 2 > 3 > Z | Popo le Chien
• 1 > 2 > 3 > Z | Erdrokan
• 2 > 3 > 1 > Z | guillom
• 2 > 3 > 1 > Z | ~Pyb

 

Décompte selon la méthode Condorcet

Options possibles :

• 1 — tous les utilisateurs (IP comprises)
• 2 — les utilisateurs auto-confirmés (autoconfirmed)
• 3 — le groupe abusefilter ou les administrateurs si le groupe abusefilter n'est pas créé au point A.
• Z — Aucune de ces propositions

Duels :

• Duel entre 1 et 2 ⇒ 2 (à 64 contre 25, 1 indifférents)
• Duel entre 1 et 3 ⇒ 3 (à 52 contre 37, 1 indifférents)
• Duel entre 1 et Z ⇒ 1 (à 89 contre 0, 1 indifférents)
• Duel entre 2 et 3 ⇒ 2 (à 86 contre 3, 1 indifférents)
• Duel entre 2 et Z ⇒ 2 (à 89 contre 0, 1 indifférents)
• Duel entre 3 et Z ⇒ 3 (à 88 contre 0, 2 indifférents)

 

Vainqueurs potentiels :

• 2 — les utilisateurs auto-confirmés (autoconfirmed)

Vous qui êtes humains, n'oubliez pas de prendre en compte les commentaires de vote.

Machinalement — Arkbot ^✉ [mes sources] 25 février 2010 à 11:05 (CET)

Merci - j'avais anticipé tes conclusions et mis ce matin wikipédia:AbuseFilter à jour et partiellement Aide:AbuseFilter. Il reste à demander la mise en place de l'extension, ce que je saurais faire sans hésitation. TigHervé (d) 25 février 2010 à 12:09 (CET)

Merci TigH .

C'est vrai qu'on n'en avait pas discuté, mais n'active-t-on pas abusefilter-revert pour le groupe abusefilter ? Si un filtre cause des problèmes, ça pourrait être bien pratique (même si bien sûr, on préfèrerait que ça n'arrive jamais). — Arkanosis ^✉ 25 février 2010 à 12:18 (CET)

De rien :)

Les dernières investigations de Kropot avaient concluent qu'il s'agissait de reverter tous les effets d'un filtre et pas seulement le dernier. On ne peut donc prendre en compte cette possibilité et se contenter des moyens habituels de revert. TigHervé (d) 25 février 2010 à 13:48 (CET)

Oui, oui, c'est moi qui avais testé . Cette option ne permet effectivement que d'annuler tous les effets d'un filtre sur une plage de temps donnée ; ça reste utile si un jour on se rend compte que malgré les précautions qui ont été prises, un filtre a fait des dégats (après une mise à jour, par exemple). Il n'est pas ici question de donner ce droit à tout le monde. — Arkanosis ^✉ 25 février 2010 à 14:08 (CET)

Oups, c'est vrai que vous aviez été en interaction sur cette question nébuleuse .

Autrement, je ne vois pas où le choix se fait (lors de la demande probablement). Mais, cette décision semble relever d'une prise de décision puisqu'il n'en était pas question dans la précédente. Je pense qu'on pourra voir ça bien plus tard, non ? TigHervé (d) 25 février 2010 à 14:21 (CET)

Oui, ce serait à la demande — le sysadm aurait une ligne à ajouter dans le fichier de configuration de MediaWiki, comme ci-dessous. Bien sûr, c'est quelque chose qui peut être discuté après coup ; il faut juste commencer — Arkanosis ^✉ 25 février 2010 à 14:29 (CET)

$wgGroupPermissions['abusefilter']['abusefilter-modify'] = true;
$wgGroupPermissions['*']['abusefilter-view'] = true;
$wgGroupPermissions['abusefilter']['abusefilter-revert'] = true; // comme ceci
$wgGroupPermissions['sysop']['abusefilter-revert'] = true; // et / ou comme cela

Merci de ce concret comme j'aime :)

Tu ne réponds pas sur la question de la prise de décision. Tu peux ouvrir une (sous-)page vantant cette possibilité et lui donner la forme de sondage le moment venu ; après discussions si tu y tiens, on pourra faire la demande... TigHervé (d) 25 février 2010 à 14:36 (CET)

Oui, je vais faire ça — par la même occasion je demanderai si on est prêt à activer une éventuelle nouvelle fonctionnalité pour annuler une unique action d'un filtre, et le cas échéant à qui on donne ce droit ; ce sera autant de temps de gagné. — Arkanosis ^✉ 25 février 2010 à 15:05 (CET)

De la lecture des résultats pour la question 3.A

Les huit contributeurs qui ont voté « pour le groupe abusefilter dont les administrateurs » sont difficilement classifiables. Soit on les décompte dans dans la section groupe abusefilter et donc leur volonté que les administrateurs fassent partie de ce groupe n'est pas prise en compte. Soit on les prend en compte dans la section administrateurs et donc leur volonté que des non-admin puissent modifier les filtres n'est pas prise en compte. Le point qui est fort gênant ici c'est que de leur décompte dépend le résultat du vote. Et si on choisit de ne pas les décompter du tout, le résultat s'en trouve également biaisé. Nous sommes, il me semble, devant une impasse... Auriez-vous une solution à ce problème ? Udufruduhu (d) 25 février 2010 à 12:26 (CET)

Pas de vraie solution, mais on en parle juste au dessus — Arkanosis ^✉ 25 février 2010 à 12:52 (CET)

Demander aux huit votants de préciser leur vote. Skippy le Grand Gourou (d) 25 février 2010 à 12:59 (CET)

Le décompte ne dépend pas des résultats. Il n'y a que deux choix : admin et abusefilter, le troisième choix n'est qu'une option pour le groupe abusefilter. De plus, quel que soit le décompte, le groupe abusefilter n'exclut pas les administrateurs. En revanche le groupe administrateur exclut les éventuels candidats qualifiés mais qui n'auraient pas de balai. Je pense que le choix doit être celui du groupe le plus ouvert. A la communauté ensuite d'évaluer chaque candidature, et éventuellement d'accepter plus facilement celles des admins. Pachycephale (d) 25 février 2010 à 13:15 (CET)

Personnellement j'ai voté en connaissance de cause dans cette section inclue dans la section abusefilter. En fait ce que je voulais c'est que cette possibilité ne soit pas limitée aux seuls administrateurs : soit en créant un groupe abusefilter et en y mettant les gens volonatires (suivant une procédure à déterminer) administrateurs ou pas, soit en mettant les permissions qui vont bien au groupe des administrateurs et au groupe abusefilter. Nakor (d) 25 février 2010 à 13:29 (CET)

oui moi aussi. J'avais pas lu la section ci-dessus, et la solution proposée par Kopro me satisfait. Donc je ne vois plus de problème. Merci pour vos réponses. Udufruduhu (d) 25 février 2010 à 18:11 (CET)

Wikipédia:AbuseFilter/Premiers pas

Indépendamment de la section précédente, mais dans la ligne de ma proposition plus haut, j'ai fait un brouillon du programme à réaliser, avec surtout la proposition de former un premier groupe improvisé de « façonneurs de filtre ».

Ici donc Wikipédia:AbuseFilter/Premiers pas

TigHervé (d) 25 février 2010 à 13:02 (CET)

Je n'ai pas vu la section où s'inscrire pour faire partie des pionniers . Nakor (d) 25 février 2010 à 13:39 (CET)

On pourrait ouvrir Wikipédia:AbuseFilter/Groupe-test. Cette page serait une brève étape « expérimentale » avant l'ouverture de la page proposée par Kropotkine_113 qui durablement servirait à la prise en compte de toutes les demandes selon l'idée de base d'un groupe abusefilter. Dans Wikipédia:AbuseFilter/Groupe-test, les bureaucrates auraient l'entière responsabilité de valider les candidatures sans s'appuyer sur des critères généraux ; il leur reviendrait également de stopper les admissions quand l'importance du groupe serait suffisante pour la phase de mise en place. Il faudrait donc que les candidats fassent assez consensus, c'est-à-dire que pour eux les candidats administrateurs seraient nettement préférables, mais tout autre utilisateur de même degré de confiance peut être admis conformément à la prise de décision.
TigHervé (d) 25 février 2010 à 14:13 (CET)

Puisque vous avez besoin d'un POV de bubu, je redonne celui que j'ai donné hier sur IRC.

• A court terme la solution proposée (groupe test) est une bonne chose. Pour plus de simplicité, je propose qu'il y ait une large majorité admins, avec 1 ou 2 non-admins pour tester le cas de figure - idéalement il faudrait des candidats pour lesquels on n'ait même pas à se poser la question de leur compétence (pour être franc je pense à des anciens admins, si Nakor ou Moyg se sentent par exemple). Une dizaine me semble suffisant, on n'en fera pas une maladie s'il y en a 15. Pour cette partie, pas besoin de consultation communautaire (selon mon interprétation de la PDD aussi l'accession d'admins doit être automatique).
• Après quelques semaines de test, il me semble que la meilleure solution qui ressort de la PDD est une inclusion de tous les admins par défaut (on ne leur ajoute pas le groupe un à un, mais on ajoute les droits au package admin par défaut), auxquels on adjoindrait un groupe Abusefilter (composé donc exclusivement de non admins, exactement de la même manière que le groupe exemption de blocage par exemple). Pour l'accès à ce groupe Abusefilter, il faudra effectivement une sorte de consultation communautaire simplifiée - ce n'est pas aux bubus de décider laquelle mais à vous de voir.

Voyez aussi avec Popo et CK ce qu'ils en pensent. Clem (✉) 25 février 2010 à 14:37 (CET)

Cela ma parait être une bonne idée. Nakor (d) 25 février 2010 à 14:45 (CET)

Sur la même longueur d'onde que Clem. Popo le Chien ^ouah 25 février 2010 à 14:47 (CET)

DarkoNeko miaou veux être dans le groupe test ! 25 février 2010 à 14:47 (CET)

Ça roule alors !
Seulement avant d'ouvrir la page des candidatures-test, comme je sens un peu de précipitation, il me paraît important que les bureaucrates soient libres de choisir les candidats sans être lié par l'ordre d'apparition. Ne serait-il pas préférable que la page reste ouverte une bonne semaine avant que les premiers statuts soit activés ; de toute façon, l'extension n'est pas en place. TigHervé (d) 25 février 2010 à 15:03 (CET)

Pas de problème: on peut ouvrir la page de "candidature" (plutôt lister les volontaires - ce n'est pas vraiment une consultation, s'il y a moins de 15 candidats dont la plupart sont admins sauf cas particuliers, ils auront tous le statut) dès aujourd'hui, ça permettra de gagner du temps. Et quand le statut sera activé on accordera les statuts. Clem (✉) 25 février 2010 à 15:11 (CET)

J'ai créé la page, vérifiez que ça vous va, commencez à vous inscrire et je ferai ce soir une annonce sur le BA (vu que dans un premier temps ce groupe test concerne surtout les admins). Clem (✉) 25 février 2010 à 15:23 (CET)

Bien pour moi.
Merci quand même de sortir une chaise pour Kropotkine ça serait sympa : à sa rentrée, il sera sûrement partant ;) TigHervé (d) 25 février 2010 à 15:40 (CET) Je me suis permis de modifier le code wiki pour que le lien redirige vers le « bon » Kropotkine (le 113). Pachycephale (d) 25 février 2010 à 18:32 (CET)

Bien vu - je note !

Je serai absent demain - j'invite les futurs membres du groupe test à se pencher sur au moins deux question préalables à toute création. C'est ici Discussion Wikipédia:AbuseFilter/Premiers pas.
TigHervé (d) 25 février 2010 à 20:01 (CET)

Bugzilla

Question subsidaire: quelqu'un a fait la demande sur Bugzilla? Si oui quel est le numéro de bogue? Nakor (d) 25 février 2010 à 15:34 (CET)

22650. Elfix ↗^discuter. 25 février 2010 à 22:24 (CET)

lien direct --Hercule ^Discuter 25 février 2010 à 23:13 (CET)

désolé, j'ai oublié de placer le lien - merci Hercule. Elfix ↗^discuter. 25 février 2010 à 23:27 (CET)

Sondage complémentaire

Je signale le sondage Wikipédia:Sondage/Accès au groupe AbuseFilter des administrateurs et non-administrateurs. Avis préalables ou participation souhaités. TigHervé (d) 28 février 2010 à 16:03 (CET)

Je ne suis pas convaincu par l'utilité de la première question - disons que les conséquences sont mal définies. Vu la PDD, quoi qu'il arrive les admins pourront obtenir le statut automatiquement (sans même qu'il y ait la moindre question d'appréciation). Que peu d'admins l'utilisent effectivement est-il un problème? En fait ma crainte est que si seuls une vingtaine d'admins demandent le statut, cela soit perçu comme une sorte de nouveau statut de plus, et vu la relative paranoïa (mot volontairement choisi) par rapport au cumul des statuts (encore pire avec des statuts perçus comme rares) on se retrouve avec des emmerdes de plus à devoir gérer (et à faire de la com' en expliquant que non, les admins+abusefilter ne sont pas une sorte de classe "au dessus" des admins). C'est pour ça que j'avais proposé que la fonctionnalité soit ajoutée au package d'admin par défaut (sans avoir à donner aux admins un statut supplémentaire), exactement comme par exemple l'exemption de blocage (les admins l'ont automatiquement, les non-admins peuvent l'avoir). En quoi est-ce que ce serait problématique/nécessiterait un choix? Clem (✉) 28 février 2010 à 17:23 (CET)

On peut sûrement faire sans cette question et faire comme tu le proposes. On peut aussi considérer qu'on peut se donner le moyen de voir les avantages et inconvénients des deux formules. Moi je ne suis convaincu ni des uns ni des autres, alors je demande l'avis général.

Il se trouve quand même que je vois spontanément les choses autrement que toi. D'abord, je lis aussi la PDD comme l'expression d'un désir de tenir les prérogatives des administrateurs en l'état sans en ajouter à l'occasion de cette extension, même si certains s'expriment nettement dans le sens que tu retiens. Il me semble que le souhait d'une collusion entre les deux statuts ne s'est jamais assez nettement exprimé au point d'en tirer des conséquences au niveau des options. Maintenant, on peut s'interroger et faire des hypothèses sur les motifs de souhait d'un nouveau groupe qui ne serait pas seulement une question d'ouverture plus large que les sysops ; les opinions sont probablement très variées comme d'habitude. Je peux penser que les admins sont déjà assez considérés comme une classe à part et leur ajouter des pouvoirs n'arrangent rien. Certes la question du cumul est une rengaine, mais là on est dans le technique et la maintenance, pas dans d'éventuels conflits d'intérêt. Avec ton option, les administrateurs ont encore plus de pouvoir en vertu du logiciel, ils ne cumulent pas les responsabilités. Pour ta question suivante, ce gain de pouvoir ou superpouvoir est théorique dans l'optique du sondage (introduction) considérant que la majorité des administrateurs n'a que faire des filtres ou de leur maintenance. Pourquoi le leur donner sans formalité ? Pourquoi les dispenser d'une simple formalité quand la justification du goupe abusefilter est de dispenser certains de se présenter au préalable comme administrateur pour pouvoir bidouiller les filtres ? Tu considères que tout cela revient au même, mais d'autres peuvent aussi considérer que les administrateurs en poste n'ont pas été désignés pour d'autres prérogatives que celles propres à leur statut.

Je pense enfin en effet beaucoup au grand nombre d'administrateurs qui ne se mêleront jamais de ces questions, et même je peux imaginer qu'un dérapage de leur fait ou de quelqu'un ayant récupéré leur mot de passe soit dommageable.

Je ne suis pas convaincu de la pertinence de ton option, pour ces raison ; c'est pourquoi je pose une question : quelle que soit la réponse, il n'y aura plus qu'assumer le choix majoritaire (si tu veux...). TigHervé (d) 28 février 2010 à 18:57 (CET)

Assez d'accord avec TigHervé même si je ne suis pas absolument opposé à la solution proposée par Clem et que je comprends ses arguments. Si il y a création d'un "groupe test abusefilter", c'est dans l'idée que l'expérience accumulée par les testeurs et que les retours de toute la communauté serviront de base de travail pour la suite. Ceci afin de prendre des décisions éclairées, de prendre le temps de réfléchir aux conséquences possibles, de faire passer au plus grand nombre l'information la plus claire et la plus précise possible. Abusefilter va être mis en route par des gens compétents et en qui la communauté a confiance. Rien ne presse, pourquoi se précipiter ? Il y a une urgence à ce que tous les administrateurs puissent intervenir ? Personnellement, même si je ne remets pas en cause l'octroi des droits au admins qui en font la demande, je préfèrerais savoir lesquels veulent s'impliquer, au fil de leurs demandes. Il se pourrait qu'on s'aperçoive à long terme qu'être admin n'est pas suffisant pour disposer de ces nouveaux outils. Ou que les batailles rangées entre armées d'admins se révoquant et se bloquant les uns les autres ne sont pas favorables à la bonne gestion des filtres. C'est peut-être un détail, mais la paranoïa n'a pas qu'un seul visage. Pachycephale (d) 28 février 2010 à 19:13 (CET)

Il n'a jamais été question de donner le statut immédiatement à tout le monde, c'est bien pour ça qu'un groupe de test a été ouvert. Après, il y a un point clair dans la PDD: 49 personnes sur 88 souhaitent que les admins obtiennent le statut. C'est un fait que le sondage ne remettra pas en cause. Après la discussion ne porte que s'ils doivent en faire la demande (et l'obtenir automatiquement, avec le besoin de faire une requête, le fait qu'ils auront 2 statuts disjoints...) ou si on peut éviter à tout le monde cette formalité . Clem (✉) 28 février 2010 à 19:21 (CET)

Oui, c'est bien ce que j'avais compris. Mais faire une démarche pour avoir des outils supplémentaires, même automatiquement, et aller bricoler un truc tout de même très sensible au grès des ses inspirations, de ses insomnies ou de ses humeurs, c'est pas tout à fait la même chose. Quoiqu'il en soit, je fais confiance aux futurs "filtreurs", mais je ne pense pas que la transparence nuise à leur travail. Ni la patience. De plus une liste du groupe abusefilter incluant tous les admins, dont ceux qui sont inactifs et ceux qui se foutent des filtres, est parfaitement inutile. Une liste des personnes qui ont clairement exprimé leur implication en s'inscrivant quelque part est plus pertinente. Et pour les statuts disjoints, c'est à dire des groupes différents pour des droits différents, je préfère considérer cela comme une sécurité et une bonne méthode pour les éventuelles évolutions futures que comme un problème. Mais comme je le disais, ce ne sont peut-être que des détails et je n'insisterai pas plus. Pachycephale (d) 28 février 2010 à 21:24 (CET)

Extension installée

Tout est dans le titre Kropotkine_113 16 mars 2010 à 21:47 (CET)

\o/ Nemoi a laissé un message ici le 16 mars 2010 à 22:04 (CET).

Tss, je débarque après la bataille... faut vraiment que je prenne Internet à la maison — Arkanosis ^✉ 17 mars 2010 à 10:38 (CET)