Community Wishlist Survey 2017/Admins and stewards/Make AbuseFilter easy to use for nontechnical admins by making filter editing more visual

From Meta, a Wikimedia project coordination wiki

Make AbuseFilter easy to use for nontechnical admins by making filter editing more visual

  • Problem: AbuseFilter is very powerful and flexible. There are plenty of situations where it could be a more appropriate tool than blocking or page protection (see e.g. all the proposals about limited blocks of problem users), and can handle spammers and sockpuppeteers who can defeat all other tools. Unfortunately it was written by tech people for tech people. Most admins are effectively excluded from using it because it's presented like a programming language, even though its concept is not that difficult (simple statements using "and" and "or").
  • Who would benefit: Admins and the communities they work for.
  • Proposed solution: Make AbuseFilter intuitive and easy to use for everyone by
    • replacing (or, preferably, complementing) the programming-language-like interface with some kind of visual condition editor (Blockly would be one good candidate);
    • integrating a decent regex editor (good example: regex101);
    • merging the filter editing / creation interface and the filter testing interface: show what the filter would match as it's being edited.
  • More comments:
  • Phabricator tickets:


Tgr: Good proposal, but at the moment it's very broad – making the tool easier to use, and then a number of different things we could potentially do. I'm worried that if people vote for this, hope for something and the team then does some of the potential proposals but not what people were hoping for, they'll be disappointed. Could we narrow it down a bit, make it more specific? /Johan (WMF) (talk) 17:22, 20 November 2017 (UTC)Reply[reply]

@Johan (WMF): do you mean changing the title to better match the three specific things proposed, or removing (splitting up? if that's OK to do past the proposal deadline) the proposed solutions so there is one technical task per proposal? Tgr (talk) 20:55, 20 November 2017 (UTC)Reply[reply]

I think there could be a number of ways to go about that – either splitting it up, rephrasing it, or focusing more on specific solutions (e.g. "here are the things I think should be done" instead of "some potential solutions") or problems. Just so we don't end up in the situation where everyone who wants something done about the AbuseFilter think this is the task and then the Community Tech team ends up focusing on something else than they were hoping for. /Johan (WMF) (talk) 21:22, 20 November 2017 (UTC)Reply[reply]
The "proposed solutions" section seems pretty specific to me: it lists the three things which IMO should be done - make a visual condition editor, integrate a regex visualisation/testing tool, live-update the list of matches as the filter is being edited (or at least make it easy to update them, without having to context-switch and copy-paste between the filter edit page and the filter test page). I only mentioned the specific technologies/tools I had in mind as examples because I haven't done the investigation needed to be sure they are viable. --Tgr (talk) 21:36, 20 November 2017 (UTC)Reply[reply]
And the three features are interdependent (at least in my mind) - they visualize different aspects of the filter (logical structure, regular expressions, actual effect on edits) that a non-technical person would have a hard time understanding from the current interface. --Tgr (talk) 21:38, 20 November 2017 (UTC)Reply[reply]
Tgr: Reading through this again, I'm wondering if I didn't read "situations" as "solutions" first. Mea culpa. But I think a more specific title would be a good idea. (: /Johan (WMF) (talk) 14:41, 22 November 2017 (UTC)Reply[reply]
Renamed. --Tgr (talk) 19:31, 22 November 2017 (UTC)Reply[reply]
I see the third feature as the critical one. If it's easy for non-technical people to edit abuse filters, it must be easy for them to see what their filters will do. For an example of what happens without this feedback, see the history of the Enwiki titleblacklist from around 2008, where a user without a good understanding of regex managed to do things like block all pagemoves to titles containing the letter "p", or block a randomly-selected quarter of all pagemoves. --Carnildo (talk) 23:58, 28 November 2017 (UTC)Reply[reply]