Wikipedia talk:Edit filter/Archive 7

From Wikipedia, the free encyclopedia

Contents

Request for permission for PhantomTech

WITHDRAWN:
One week without support and a few days with no activity. PhantomTech (talk) 06:20, 2 April 2015 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

PhantomTech (t · c · del · cross-wiki · SUL · xtools · supercount · pages created (xtools • sigma· non-automated edits · BLP edits · logs (block • rights • moves) · rfar · spi) (assign permissions)(acc · ap · fm · mms · npr · pm · pcr · rb · te)

I started working with these filters about two weeks ago in false positives, since then I've been pretty active in that area and doing a bit in the filter requests section. Right now I can't view some of the filters which delays (admittedly not by too long) some false positive reports that I otherwise wouldn't have a problem dealing with. Additionally I've been working on User:ThePhantomBot, a bot that detects LTA among other things, and going through the filters to see which can be offloaded onto my bot would help cut down the total number of edit filters. To be clear, I don't plan on disabling any filters that I set my bot to detect until my bot has been approved and the filter in question has been tested with my bot. I'll admit that two weeks isn't a long time for working on filters, but hopefully I've shown that I can be trusted to not do something reckless. I have quite a bit of experience with regex coming from having to make a regex based chat filter for something off-wiki. PhantomTech (talk) 21:52, 25 March 2015 (UTC)

Discussion
  • Oppose this is one of the most dangerous user rights, and your on wiki editing experience is fairly limited (edits appear to primarily be through the use of automated tools in patrolling articles) - not enough to demonstrate the high level of trust this right requires. On a side note, your bot request hasn't even entered the trial phase yet. Will this stall it, or will you be able to proceed with publicly visible filters? — xaosflux Talk 05:46, 26 March 2015 (UTC)
@Xaosflux: I don't think this permission request being denied will affect how long it takes my bot to get into a trial phase, there is probably enough public information in LTA and SPI to get a good amount of additional filters setup. Even if there isn't, your opposition seems to be about me being able to mess with the filters, not see them, so if I really needed them for some reason I don't think it would be a problem to have a few of the private LTA ones sent to me. PhantomTech (talk) 06:41, 26 March 2015 (UTC)
Copies would certainly be possible. It seems like you really would only need abusefilter-view-private access for most of the work you want to do (as opposed to the dangerous abusefilter-modify permission), unfortunately the only usergroup with that permission is Administrators. A new user group "Edit filter reviewers" or the like could be created to allow private-read access, if community consensus could be demonstrated (perhaps in a new section below). It would have a lower barrier to entry, you are not the first person who has asked for this type of access (e.g. sysops of other projects that want to copy our filters). — xaosflux Talk 10:18, 26 March 2015 (UTC)
Proposed new group in thread below, please comment as desired. If it gains traction, will cross post to WT:PERM and WT:AN. — xaosflux Talk 17:56, 26 March 2015 (UTC)
  • Oppose due to the lack of data that indicates the required experience in making changes. Feel free to copy publicly visible filters to testwiki: and modify them or request private ones copied there for you to make changes or see how they work for your bot as needed, but I don't think it is wise to allow access on enwp without some indication of experience and ability to saftely work on these. If you require permission on testwiki, please let me know and I'll happily help you there. — {{U|Technical 13}} (etc) 11:07, 26 March 2015 (UTC)
@Technical 13: If your main concern is about my competence with edit filters I don't mind being quizzed. If you want to make up a few scenarios for filter requests or something, I wouldn't mind telling you how I would deal with them, including any filters I would set up. PhantomTech (talk) 15:20, 26 March 2015 (UTC)
  • I've not found "quizzes" to be common practice on Wikipedia, and that may be because they are not the best way to gauge competence. Practical demonstration seems to the most effective way, and I understand if you are wondering how you are suppose to get practical experience without the ability to actually do it (hence you might think it is a catch-22 that you can't have the bit to make changes because you haven't demonstrated competence of making changes with a bit you don't have). That is the reason I have offered to give you the bit on testwiki: where you can create and copy and change filters and get practice and see how it actually works. I'm sure that after 3-6 months of you actively making changes and not blowing everything up, your chances of getting the bit here will have greatly improved (although I won't guarantee you the bit at that point as I do not have the power to grant you the bit and I wouldn't make such a promise anyways on the grounds that I'm not the only one who has opposed at this time and a consensus of some scale would need to be achieved first. — {{U|Technical 13}} (etc) 15:54, 26 March 2015 (UTC)
@Technical 13: I'm not sure exactly what the difference between a demonstration using current filters and describing what I would do related to filters given a certain situation is in terms of a show of competence. A simple test (what regex matches this string) would hardly do anything in terms of demonstrating competence, but I'm suggesting more complicated and realistic tests. Asking me to make a filter for an LTA case that currently isn't active enough to have a filter and assuming for the sake of the test that it is active enough is the level of tests I was expecting. I know there aren't quizzes used for anything on Wikipedia but I think they'd do a much better job here as a display of competence than most other places, especially because of how important competence is here. Maybe it's the time that you're concerned about, working over a few months would likely involve a lot more "tests," and therefor be a better test overall, than you might be able to make up for me in a few days. PhantomTech (talk) 16:23, 26 March 2015 (UTC)
  • The difference is, in order for you to be tested adequately, you would have to have an admin or someone else sufficiently capable of giving you the bit upon completion that would be willing to spend months with you. I can't foresee that happening and the best thing is to just practice in a safe environment (like testwiki) and actually refine existing filters and make your LTA filter and whatever else over a few months. If you are interested, please email me and I'll give you the admin bit for this on testwiki and you can get started, otherwise, I think this is a discussion that is blowing in the breeze and not accomplishing much. — {{U|Technical 13}} (etc) 19:25, 29 March 2015 (UTC)
There is no abusefilter group at testwiki (only admins have access). Since this comes up on occasion, I think I'll add one along with phab:T93798. (see phab:T94214) Cenarium (talk) 18:22, 27 March 2015 (UTC)
  • I'd be happy to give anyone that requests something of this nature the admin bit on testwiki within reason of course. I'm not convinced there is a need for there to be a specific EF group there, that said, I won't object if you want to make one. — {{U|Technical 13}} (etc) 19:25, 29 March 2015 (UTC)
  • Comment Just to be clear, are you saying you wont edit the filters at all? Or just not delete them? Soap 15:29, 26 March 2015 (UTC)
@Soap: When moving filters to my bot, prior to it being approved, I won't edit them at all, this means I'll only be able to work with filters that are in log only mode or that are currently overly specific as a result of the limitations to what filters can check and to keep their false positives low. If my bot is approved, when moving filters over they'll be switched to log only if they aren't already and then disabled once my bot is effectively detecting and dealing with them. If you're considering approving this permission on the condition that I never edit filters I'd recommend not doing so, for my request and for any others. If the concern is not being able to trust my intentions with the filters then it wouldn't make sense to trust that I won't edit them, sure you can remove the permission if I do edit them but you'd do that anyway if I made it clear I meant to cause harm. If the concern is about competence then, like I said to Technical, I don't mind being quizzed with however many scenarios you want to throw at me. As a final note, realizing that filters can have big effects on Wikipedia, I will, as anyone should, ask someone else about a change if I'm not sure about it, including any filters I'm not sure if should be moved to my bot. PhantomTech (talk) 15:49, 26 March 2015 (UTC)
  • Based on this comment, I'm not sure you understand how the wiki works sufficiently. This comment gives me pause and indicates to me that concern about you having this right, or having a bot, isn't entirely invalid. I recommend you read over our bot policies and reconsider your comment here, perhaps you would like to make some clarifications? — {{U|Technical 13}} (etc) 19:25, 29 March 2015 (UTC)
@Technical 13: I've read the bot policy and I'm not aware of any problems with what I'm currently doing or plan to be doing in relation to it. Based on your reply above about making LTA filters on testwiki and your reference to the bot policy here I'm assuming there's been a miscommunication about what my bot is/will be doing, if your concern was about something else let me know. My bot is currently operating with a low edit rate in its own user space and will continue to do so unless it gets approved. I have no intention to replace all abuse filters with my bot. In relation to LTA cases the goal of my bot is to be used to detect any that either cannot have an abuse filter setup for them (either because of technical limitations or because they would hardly ever be used) or that do not need to be done by abuse filters. An example of a filter that doesn't need to be an abuse filter is Special:AbuseFilter/663 which could be dealt with by my bot to reduce the total amount of abuse filters, moving a single filter to my bot would be pointless but it's not like there's a shortage of LTA cases or related filter requests. Right now all my bot does when it detects something is report it, that's also almost definitely the only thing it will be approved to do, if it is approved, the only difference being where it reports to and how often it is allowed to do it. If I get the abusefilter permission while my bot is unapproved it will be used primarily for reading filters for false positives (Cenarium has pointed out that there is a global right that can be used for this) and adding any filters that are set to log only to my bot, leaving the filters themselves untouched. The few times I will actually change filters prior to my bot's approval is to fix bugs that cause false positives, no changes will be related to my bot. If my bot is approved I will, for appropriate filters, add the filter to my bot (as log only) and then change the abuse filter to log only, once my bot has been tested with the filter I'll fully enable it on my bot and disable it from abuse filters. I do plan on helping some with filter requests but don't plan on doing this anymore than I do now until after I'm done with most of the work for my bot. Again, if I didn't clarify the part you were concerned about or something is still unclear please let me know. PhantomTech (talk) 20:43, 29 March 2015 (UTC)
  • The few times I will actually change filters prior to my bot's approval... should be "none". I'm not an admin, so I can not give you the bit, but I've been around here long enough to know that this request is very likely to be ultimately declined. Your lack of interest or willingness to spend time reading and modifying filters on testwiki first by requesting them be copied there and making edits there and requesting changes be made here based on your changes there is an indication that you probably should not have the bit to even read the filters here. Based on this, I'm no longer willing to give you the bit you would need on testwiki to make this happen. I'm no longer going to watch this discussion, and I wish you luck if you wish to pursue this request further. — {{U|Technical 13}} (etc) 21:35, 29 March 2015 (UTC)
Again, my changes to the filter prior to my bot's approval will not be related to the bot. I don't see a problem with editing filters to fix false positives, I think I have enough experience with regex and programming to do it without messing things up, if someone disagrees or thinks I haven't proven it that's fine and I can't really do anything but offer to prove I'm capable. Having filters moved to testwiki for small changes to fix false positives then back here seems like an unnecessary prolonging of the process, I currently post recommended changes on the related page (false positives or requests) and think it's much more efficient, sure for big changes it would be best to do some testing first but I don't plan on making any of those any time soon. Even if I was completely incompetent when it came to making changes to filters, I don't see what that would have to do with having the read permission. PhantomTech (talk) 21:56, 29 March 2015 (UTC)
  • If a filter ends up no longer needed, an edit filter manager can disable it, so there's no actual need to edit filters. If you need to see private filters, a global usergroup exists for this, see m:Abuse filter helpers. I do not believe we should grant view-only access since this group exists, I suggest you request it at meta. Cenarium (talk) 20:30, 26 March 2015 (UTC)
@Cenarium: I realize if my bot was the only reason I'd be doing anything with filters that it would probably make more sense to just have someone else make the changes but I do plan on working with filters unrelated to my bot, mostly fixing false positives that come up and, once I'm not so busy with my bot, I might start working through some of the filter requests. PhantomTech (talk) 04:23, 27 March 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Question for curiosity

What does "GP disruption" mean? --TL22 (talk) 01:52, 3 April 2015 (UTC)

This is a private filter, the GP refers to part of the vandalism target and is meaningless outside of that filter. — xaosflux Talk 01:59, 3 April 2015 (UTC)

Run time

Resolved
Adjustment has reduced last runtimes from 50+ms to <1ms.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

We've had lengthy discussions about conditions and the condition limit, but what governs how long an edit filter's run time is? I bring this up because Special:AbuseFilter/673 seems to be taking around 57ms, which is colossal compared to others and I can't see why; it's a pretty short filter. Sam Walton (talk) 09:20, 5 April 2015 (UTC)

This is a very broad filter, @Samwalton9: - is this an issue with "creating" pages, or editing - it is currently searching all the text of most edits. — xaosflux Talk 15:34, 5 April 2015 (UTC)
Of course, I somehow hadn't realised how broad it was. I've reduced it to IPs & new accounts. Sam Walton (talk) 15:44, 5 April 2015 (UTC)
Thanks, seems to have solved it, New average run time is: 0.6 ms. — xaosflux Talk 15:58, 5 April 2015 (UTC)
I've said it before and let me say it again. Condition and run time numbers are prone to profound corruption and these stats should not be trusted. phab:T53294 Dragons flight (talk) 07:06, 6 April 2015 (UTC)
Thank you @Dragons flight:, looks like there was some room for improvement on that one as well. — xaosflux Talk 13:29, 6 April 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Disabled inactive filters

I went through the least active 50 filters and disabled two that haven't had any hits this year: 311 and 358. Dragons flight (talk) 18:06, 8 April 2015 (UTC)

Edit filter helpers

I propose to create a new user group "Edit filter helpers" (local version of global group) that has the abusefilter-view-private permission applied to it. Also propose to add +/- group changes to this new group to the existing administrators group. This will allow us to grant view access to users that only require the access to view private filters, but do not meet the thresholds to be able to modify them. Potential candidates would be non-enwiki admins that operate certain bots, guest admins and efm's from other wiki's that want to re-use our settings, users that may respond to false positive reports.

Technical proposal
  1. Create enwiki local user group abuse filter helpers
  2. Grant the abusefilter-view-private permission to this group
  3. Grant the ability to add and remove users from this new group to administrators

Discussion

  • Support, as proposer. — xaosflux Talk 17:55, 26 March 2015 (UTC)
  • Oppose as unnecessary bureaucracy. We've regularly granted EFM to people who need to see private filters on the stipulation that they don't modify them. So far, I don't think that any of them have abused their rights. Reaper Eternal (talk) 18:15, 26 March 2015 (UTC)
    I don't envision the request process to be any more onerous then it currently is, but would give the ability to grant only what is needed; respect your opinion that this could be considered process creep - I'm really just looking for a way to say "yes" to more editors. — xaosflux Talk 18:54, 26 March 2015 (UTC)
It may make more sense to have this as a global group (handled at meta). There's already a m:Abuse filter editors group, and we might have a view-only equivalent (they could view private filters on all projects).  Cenarium (talk) 20:18, 26 March 2015 (UTC)
  • Actually, there's already one, m:Abuse filter helpers, so I suggest we refer users to this group if they only want view access. Cenarium (talk) 20:22, 26 March 2015 (UTC)
  • That group may have a higher barrier, as it is for ALL projects, we could just as easily have a local group for enwiki needs. — xaosflux Talk 01:15, 27 March 2015 (UTC)
  • The target audience you give as examples is cross wiki in nature, so it's not so much about enwiki's needs; a local group would have a too small use case IMO and it makes sense to offload the bureaucracy aspect to meta where it's centralized thus more efficient. Even for users who only check false positives, it makes sense to give them the global group so they can see filters at testwiki and other wikis where the same problems may arise. I don't see why the standard should be higher, since enwiki is the most looked-after project for people interested in exporting filters in the first place. Cenarium (talk) 18:19, 27 March 2015 (UTC)
  • Support No need to give people permission to change filters if they don't need it and there are probably a decent number of people that do false positives that many editors wouldn't be willing to trust with editing filters. Like xaosflux said, the global group probably does have a higher standard. While some users might benefit from the global permission I don't think many would need it, we don't use global rollback because most people who use rollback rights don't need it globally. PhantomTech (talk) 04:14, 27 March 2015 (UTC)
Retracting support, not opposing but Cenarium makes a good point in their latest reply. PhantomTech (talk) 18:37, 27 March 2015 (UTC)
  • Oppose I really think edit filter managers can work with this. A lot of the current EFM's do very little editing, or none at all. Only someone really trustworthy can get EFM, and if they say they dont want to actually modify the filters then I think they will stick to their word. I realize that's not the central argument here, but if youre saying there should be a separate right because it's a lower barrier and therefore is easier to get, I really really think we should try to work against that mentality and give editors the full EFM access. Soap 04:20, 28 March 2015 (UTC)
    Yes, my proposal was to have a local edit filter helpers group that could read the filters and logs but not change them, as about 50% of our filters are "secret". — xaosflux Talk 04:56, 28 March 2015 (UTC)
  • Interesting proposal. I've been previously declined EFM despite being trusted enough to be a TE, as well as everything else on here under admin, despite the fact that I only wanted the right to view filters so I could copy them to testwiki to work on them where I'm a crat and then propose changes and improvements here, and despite the fact that I'm a bot operator and labs tools maintainer. Due to that, I'd like to support this proposal. On the other hand, I feel extremely resistant to that on the grounds that it's bcreep and many of the reasons cited above. So, I'm afraid I'll have to remain neutral at this time. — {{U|Technical 13}} (etc) 05:30, 28 March 2015 (UTC)
    • I've spent a little over a week thinking about this from time to time and I'm afraid that, despite my internal conflict about this, private edit filters are private for a reason. If we can't trust a user to not edit them if that is the agreement they make, then I don't see why we would trust them to view these private filters either so they can figure out how to work around them and cause disruption. A badly coded filter has the potential to cause widespread disruption not restricted to enwp. That being said, I'm officially changing my position to Oppose even if it means this is a section of the wiki I may never be able to help with. — {{U|Technical 13}} (etc) 15:54, 5 April 2015 (UTC)
  • Oppose. Those that need access to edit filters can get that right or the global "Abuse filter editors" right. Epic Genius (talk) 20:10, 8 April 2015 (UTC)
    This is about viewing filters, and the global edit right is staff-only. Vogone (talk) 14:12, 9 April 2015 (UTC)
  • Oppose, I don't see a pressing need for this to be added right now. Have there been any instances where a non-admin would need to view private edit filters but wasn't eligible for the edit filter manager right or the global edit filter helper right, or wasn't immediately helped by an admin colleague? Since this proposal covers private edit filters, I would prefer that the user be trusted as an edit filter manager instead. Nakon 02:53, 9 April 2015 (UTC)
    Yes, see just one section above. Vogone (talk) 14:12, 9 April 2015 (UTC)
    • I disagree that right above is an example of this. That user refused to be assisted by being granted the admin bit on testwiki and have admins copy over filters as needed for them to view and work on. That said, I can think of no case where there has been a need to view and the user should be trusted to view and not edit. — {{U|Technical 13}} (etc) 19:01, 9 April 2015 (UTC)
    Testwiki ain't a playground. Vogone (talk) 21:08, 9 April 2015 (UTC)

Using meta?

  • Hi from meta. My opinion does not reflect consensus there, but the general practice is to bounce users back to local wikis for rights that will only be used on one project. If the user requesting the global abusefilter helper right is going to use it xwiki then the request will be within the scope of that group, but otherwise it would be better for a local group to exist (or for the previous practice of granting EFM to trusted users for viewing only to continue) Ajraddatz (Talk) 05:47, 3 April 2015 (UTC)
    • I do not think we should continue the previous practice of granting EFM to users coming from other wikis desiring to see our filters in any case (the latest occurrence of it seems to go back to 2012). Granting EFM access is too much of a risk, in light of the BarkingFish (talk · contribs · count · logs · block log · lu · rfa · rfb · arb · rfc · lta · socks confirmedsuspected) precedent. View access isn't as critical so we don't have to preoccupy ourselves with this anymore, it is best handled at meta since importing filters is a cross wiki matter (same as importing page histories).
    As for the practice when it comes to active enwiki users needing to view the private filters on enwiki (but not editing), which is enwiki specific, I don't know of any successful request except Chzz (talk · contribs) (who no longer has it). From what I can see at false positives, there aren't lots of users without EFM that help out with those (and not being able to edit, they couldn't do much, in addition private filters code can't be discussed onwiki), so I just don't think a local group is needed as the use case would be too small. Cenarium (talk) 19:45, 3 April 2015 (UTC)
    The global abusefilter helper group is clearly not designed for users who want to copy filters from enwiki. As the group name already implies, it is designed for users who offer their knowledge to help with abuse filters on small- to mid-sized wikis, for which they may also access existing private filters across Wikimedia. I do not believe metawiki should be abused for local enwiki matters. If enwiki wants to offer a view-only right, they are free to do so, but it isn't up to the meta community to decide about user rights on this wiki. Vogone (talk) 22:24, 3 April 2015 (UTC)
    "Abused" is kind of a strong word, don't you think ? It doesn't matter what the original intention for this global group was, it should be expanded to cover such cases. You seem to think that enwiki is the only place where people might want to export filters from. This is incorrect, people might want to and as a matter of fact, already did, import filters from wikis other than enwiki to their home wiki. Who said meta should decide for us ? And again, this is not a local issue, it's a cross wiki issue : people from other wikis want to import filters to their home wiki, so need access to private filters on WMF wikis. It does not concern enwiki, enwiki is a potential import source, among many others (frwiki, dewiki, and other language wikipedias have plenty of filters that would be of a much greater relevance to small wikis in that same language). It's a matter for meta, enwiki doesn't have to burden itself with such issues, when it's clearly not equipped for this while meta is (language concerns, global activity checks, and so on). Cenarium (talk) 15:57, 4 April 2015 (UTC)
    If there is a demonstrable need for global rights (e.g. importing/exporting from multiple wikis) then yeah, we can approve such requests. But for cases like the one above, which seem to be enwiki-only, it would be better to have a local group or continue the practice of granting EFM with the agreement to not modify. Ajraddatz (Talk) 16:12, 4 April 2015 (UTC)
    I agree that this particular case seems enwiki-only. I'm willing to support creation of a local group to sort this out, even though it's likely that we'll only have a couple of members, but on the condition that it is used only for local needs. People who want to export filters into their home wiki (historically, the main motivation for such requests) should ask for the global group, since it's a cross wiki matter not specific to enwiki. Cenarium (talk) 16:38, 4 April 2015 (UTC)
    If you think the scope should be expanded, feel free to start a global process to do so. Just deciding this based on an enwiki admin's opinion would have the effect of patronising all ~ 800 other wiki communities affected. And I do not think enwiki is the only source, I only think mere export of private filters without local consent is somewhat out of the global group's scope. The scope is so limited on purpose, in order to prevent issues with local communities possibly disagreeing with their filters being exported by people they do not trust. Meta is not the appropriate place, and the Meta community is rather small and likely unwilling to deal with such requests even. Vogone (talk) 14:02, 6 April 2015 (UTC)

Feature requests

I've been doing a little patching T30844 T53294 T87862 T90754 to the AbuseFilter extension. Does anyone have any feature requests that you'd like someone to look at? (No promises.) Dragons flight (talk) 05:06, 1 April 2015 (UTC)

Console

This isn't really a request related to edit filter functionality itself, but if there were a "console" so to speak to test out all the functions like ccnorm, that would be incredible. I envision a textarea where I can type in what would be the pre-saved wikimarkup, then have a select dropdown of all the functions (ccnorm, count, str_replace, etc.), and a "Run" button that would then show me how the functions would interpret it. Right now it's more of a trial and error scenario. I edit my sandbox, then use the batch tester to run my filter against it and see if it matches the edit based on what I think the functions are doing. MusikAnimal talk 20:48, 1 April 2015 (UTC)

It already exists: Special:AbuseFilter/tools. Cheers! Reaper Eternal (talk) 20:55, 1 April 2015 (UTC)
What the... That link has been up there all this time!!!? I'm amazed I got this far without it! Geezus! By the way, there's tons of stuff in there that's not at mw:Extension:AbuseFilter/Rules format. I could work to update the docs but really the debugger is all you need. Meanwhile ironically at mw:Extension:AbuseFilter there's no mention that a debugger even exist... Surely you can see the conundrum here! MusikAnimal talk 21:07, 1 April 2015 (UTC)

Recognized keywords

It could be a useful addition to be able to check who a page's creator is. I thought this was already a feature but then couldn't find it. Sam Walton (talk) 20:58, 1 April 2015 (UTC)

Ah, apparently it's article_first_contributor, but that's not listed at mw:Extension:AbuseFilter/Rules format. Could you, while you're working on this, double check if anything else is missing from that page? Sam Walton (talk) 21:01, 1 April 2015 (UTC)
Sam, I took a stab at making a list of all recognized symbols and keywords. Perhaps you could cross-reference it with the documentation and figure out what still needs explanation. Dragons flight (talk) 21:35, 1 April 2015 (UTC)
List of all recognized symbols and keywords
'
-
!
!=
!==
"
%
&
(
)
*
**
*/
,
/
/*
:
:=
;
?
[
]
^
|
+
<
<=
==
===
>
>=
accountname
action
added_lines
added_lines_pst
added_links
all_links
article_articleid
article_first_contributor
article_namespace
article_prefixedtext
article_recent_contributors
article_restrictions_create
article_restrictions_edit
article_restrictions_move
article_restrictions_upload
article_text
bool
ccnorm
contains
contains
contains_any
count
edit_delta
edit_diff
edit_diff_pst
else
end
false
file_sha1
file_size
float
if
in
int
ip_in_range
irlike
lcase
length
like
matches
minor_edit
moved_from_articleid
moved_from_namespace
moved_from_prefixedtext
moved_from_text
moved_to_articleid
moved_to_namespace
moved_to_prefixedtext
moved_to_text
new_html
new_pst
new_size
new_text
new_wikitext
norm
null
old_links
old_size
old_wikitext
rcount
regex
removed_lines
removed_links
rescape
rlike
rmdoubles
rmspecials
rmwhitespace
set
set_var
specialratio
str_replace
string
strlen
strpos
substr
summary
then
timestamp
true
ucase
user_age
user_blocked
user_editcount
user_emailconfirm
user_groups
user_name
user_rights

Syntax highlighting

On this subject, some syntax highlighting, requested at phab:T39192, would be much appreciable for code readability. Cenarium (talk) 22:05, 1 April 2015 (UTC)

While a good idea, coding that up is more complex than anything I want to mess with right now. Dragons flight (talk) 02:42, 2 April 2015 (UTC)

Earlier filter tripping

Dragons flight, would it be possible to add the ability to check if edits have tripped other filters? Say an edit trips filter 600 and 650, I could then create a filter which looks for edits which tripped both filters. I think this could be useful for the broader edit filters; we could save on duplicating checks by simply writing 'Did the edit flag this other filter?' Not sure how hard this would be to implement though as I don't know the details of how edits are checked against filters. Thanks, Sam Walton (talk) 18:06, 7 April 2015 (UTC)

Yes, it would be possible to query whether previously executed filters have tripped. I think the filters execute in ID order, though I'd have to check that. Probably the easiest option is a list of previously tripped filters so that one could check "35 in filters_tripped" to see if filter 35 was found to have tripped. It would be more complicated to check things like what action was taken. Dragons flight (talk) 18:40, 7 April 2015 (UTC)
@Dragons flight: Checking what action was taken would be less important I think. MusikAnimal had a nice idea, that this could be implemented through a "only run this filter if filter X is tripped" checkbox on the filter's page. For an example of where this could be used see this request; Rather than duplicate the entirety of Special:AbuseFilter/135 with an addition of a negative edit_delta, I could just have that one line with "flagged filter 135" checked. This would save effort and computing time (I would imagine). Sam Walton (talk) 18:59, 7 April 2015 (UTC)
I think it's a great idea with the potential to revise the whole operation of the edit filter. For instance make Filter 1 = unconfirmed editor. Filter 2 = fewer than 10 edits. Filter 3 = fewer than 50 edits. Filter 4 = article space, etc. etc. Maybe set aside filters 1 to 99 for general checks like this. Then filter 100 would check if, say, filters 1 and 3 are passed and only if they are would it check its own specialist requirements. Would this save processing time by replacing these general checks that are repeatedly made by almost every filter with simple "triggered or not" checks?
On the other hand I could see it making the whole system more complex, and error-prone if an early filter was changed (maybe mark them read-only or warn that they have dependencies?).
Just some thoughts.  —SMALLJIM  22:36, 7 April 2015 (UTC)
I think that to save any time the filters being used in later filters would need to have checked for more than one thing; checking that a filter has been tripped likely takes as much time as checking whatever it was that filter checked. Then again I don't really know how the extension really works, so I'll let Dragons Flight say for definite. Sam Walton (talk) 23:00, 7 April 2015 (UTC)
I agree with Sam that strategies that break everything up into lots of little filters probably lose more in usability than they gain in performance. Practical scenarios when you might want to link filters would generally revolve around an expensive combination of checks. Also note that if filter A triggers, it must at a minimum create a log entry which generates a little bit of extra overhead. There is a site protection feature that any filter triggering more than 5% of the time is automatically disabled. That said, I can imagine scenarios where X behavior is suspicious enough to justify a logged / tagged action and X behavior + Y behavior is enough to justify disallowing the edit. Dragons flight (talk) 00:44, 8 April 2015 (UTC)
Ah well. It seemed an interesting idea at the time, but that 5% trigger would seem to be a killer. It would also have been necessary to stop the general filter hits from being logged and flooding the irc feed. I wonder, though, if there would be any benefit in caching the results of very common general queries such as !("confirmed" in user_groups) or (article_namespace == 0) within the edit filter system, so these queries are only made once for each edit.  —SMALLJIM  09:57, 8 April 2015 (UTC)
My understanding of the edit filter is that each edit is investigated and a set of parameters generated, those that you see when you examine an edit (Special:AbuseFilter/examine/log/11899850 for example). The software then runs through each filter checking against these parameters. As such I don't think your suggestion makes sense within the system as it currently functions. Again, this is just my understanding of how it works and I could be wrong. Sam Walton (talk) 10:00, 8 April 2015 (UTC)
Thanks Sam. Sounds like you're right: "This page allows you to examine the variables generated by the Edit Filter for an individual change". I should have rtfm :)  —SMALLJIM  11:45, 8 April 2015 (UTC)

Summary log

I don't know how much time you've got, but someone should mention, an edit/changes summary log instead of annotating changes in the notes section. Also, the ability to view a diff before saving changes. I once wanted to know if someone was editing the talk page of a blocked user, but found I couldn't. Not that common I'll admit. Thanks :) -- zzuuzz (talk) 18:15, 7 April 2015 (UTC)

Stripping HTML comments

See the history of {{UK MP links}}. I imagine that edits like those would be quite hard to trap using regular expressions, but much easier if the underlying software allowed an edit filter to test a temporary copy of the text that had the HTML comments stripped out. -- John of Reading (talk) 06:36, 8 May 2015 (UTC)

Filters triggered via Visual Editor

Messages such as a MediaWiki:Abusefilter-warning-advertising say "go to the bottom of this page and click 'Save page' again", which is incorrect if the edit was made via the Visual Editor. See WP:HD#"Your edit has triggered a filter...". Is this fixable? -- John of Reading (talk) 06:11, 16 May 2015 (UTC)

Edit filter: Beals

What is Edit filter Beals? Both a good-faith edit that I made and a good-faith edit by another editor were blocked by this filter at about 1530 GMT on 13 May. On searching, I see that there is a sockmaster named David Beals. Is this filter designed to block edits by his sockpuppets, or does it have some other purpose? I have filed a false positive report. Robert McClenon (talk) 15:51, 13 May 2015 (UTC)

I'm not sure the detail will be helpful. This filter (688) suffered from catastrophic human error at around that time. I think it ended up checking for any edit summary at one point. It's now mostly harmless. It's a reminder not to do testing while the disallow action is enabled. -- zzuuzz (talk) 00:08, 14 May 2015 (UTC)
Think to support following feature request bug at T50961
No. Feature request Benefit or Purpose Phabricator no
1 Special:AbuseLog should be filterable by action taken, e.g. "disallow" disallowing filters and disallowed edits would be monitored more effectivelly (for falls positives etc.) T50961
Mahitgar (talk) 07:52, 17 May 2015 (UTC)

Graph and property parser function in main namespace

I would like a way to keep track of where the <graph> and <property> parser functions are being used in the main namespace. Both of these are generally meant to be used more in templates and other non-main namespace pages, though curious if/how they are being used directly in the main namespace.

I am also somewhat curious about having a tag for all graphs also. (there is a page_prop, so these can be found with Special:PagesWithProps, but would be useful to find these in recent changes)

(article_namespace == 0) & (lcase(added_lines) rlike "<\s?graph")

tag: 'graphmain' (for main namespace) and possibly another filter to tag 'graph' (for all namespaces).

(article_namespace == 0) & (lcase(added_lines) rlike "<\s?property")

tag: 'property'

or we could just tags all edits with the tags

(lcase(added_lines) rlike "<\s?graph")

and then can filter by namespace in Special:Recentchanges. that might be the best option, at least for graph.

Aude (talk) 06:02, 20 May 2015 (UTC)

Incorrect statistics message

When I edit a filter (on Swedish Wikipedia) there is a label called "Statistics" and a text that shall inform about how long time it takes to run the filter and how many conditions that are used. Those values are not shown. "$4" and "$5" is shown instead. I think it started to look like this today. Does it look the same on English Wikipedia? Does anyone know what is wrong? Svensson1 (talk) 10:29, 24 May 2015 (UTC)

@Svensson1: Here it seems that the sentence has been removed entirely. Not sure why. Sam Walton (talk) 12:51, 24 May 2015 (UTC)
Without the removed information it is very difficult (or impossible) to optimize the filters concerning speed and number of used conditions. Svensson1 (talk) 13:36, 24 May 2015 (UTC)
@Svensson1: From a bit of investigating it seems that the "filter profiling" was removed with this change as part of MediaWiki 1.26/wmf7. It seems that the reason was the large amount of server time spent on updating the numbers which slowed down save times, though looking at this code change implies that something will be introduced to replace the feature (judging by the "// @TODO: log slow/complex filters" comment). I've sent Aaron (who made this change) an email asking when he thinks this might get done. Sam Walton (talk) 16:27, 24 May 2015 (UTC)

Need to revisit falls positive discussion

While going through wikipedia:Edit_filter/False_positives page, I came across Wikipedia:Edit_filter/False_positives#90.208.8.194 this discussion. While it seems to have been replied by an admin but feel there may be some scope to revisit the discussion by some admin who is experienced edit filter manager. Actually claimed (false) positive seems to be about user signature in article, hit to Special:AbuseFilter/613 and warn message is quite ok. But the filter no. Special:AbuseFilter/623 is also about simmiller purpose and it disallows edit. While filter no Special:AbuseFilter/623 is private and I can not see it but my logic is if Special:AbuseFilter/623 hits first wrong edit itself and disallows an edit then there wont be any need of Special:AbuseFilter/613, or else Special:AbuseFilter/623 should catch second attempt and not first attempt.

In any case prima facia answer given to the ip user seems to be different one than what the filters were doing ? So I felt that if the answer giving admin has exmined false positives with given filters then, let some edit filter manager peer review what exactly happening at Special:AbuseFilter/623.

Mahitgar (talk) 08:42, 1 June 2015 (UTC)

Mailing list proposal

I was thinking about ways to collaborate with many users about things like LTA cases when I realized that filter managers don't really have any effective way (that I'm aware of) to communicate about private filters. Public filters can quite easily be discussed here or on the requests page, but, for obvious reasons, private filter discussion has to be very limited in public places like these. The only currently existing ways I'm aware of that allow discussion of private filters are emailing someone (which requires you know who is going to be able to help the most) or using the filters comments, which can be seen by anyone working on the filters but probably wont be noticed unless they're actively paying attention to that filter. Since there's an apparent lack of a way to have a wider discussion about private filters, I'm proposing that a private mailing list (abusefilter-en or similar) be created. The mailing list would be meant to be used only for discussing private filters, since using other places to discuss public ones would allow for more input than the mailing list. It could also be used by non-subscribers to request private filters. Here's the meta page on mailing lists. PHANTOMTECH (talk) 23:37, 6 June 2015 (UTC)

I think this is an alright idea, though I'll be honest that I haven't personally had much need to discuss private filters. I can see the benefits though so I'll wait to see if others think it would be used. Sam Walton (talk) 08:16, 7 June 2015 (UTC)

Un-answered requests

I reported Wikipedia:Edit_filter/Requested#Persistant_spam this request. For confidentiality purposes if edit filter managers do not want give details what they will be doing or not doing is quite ok. But atleast if some one replies saying that the message has been taken note of then reporting person will feel good and report it again next time. It is not about my request, but otherwise also co-operating users are dealt with un understood silence may be revisited by edit filter managers.

Rgds Mahitgar (talk) 09:04, 1 June 2015 (UTC)

Hi Mahitgar. Honestly this is just a case of there only being a handful of admins who are actively creating edit filters. We end up prioritising the most important ones both for time and resource purposes. We're steadily making our way through the list though. Sam Walton (talk) 08:17, 7 June 2015 (UTC)

User:Samwalton9 yes, I understand this dificulty..Any way I have noted few more instances of the same spam at Wikipedia:Edit_filter/Requested#Persistant_spam latest being dated 8th June. Rather than those admins doing the same deletion work again and again if they spare a little time over with edit filter, it may save their valuable time. But alas, at times saving of time and efforts also takes its own time.

Thanks for your reply and best wishes

Mahitgar (talk) 17:38, 8 June 2015 (UTC)

Edit filter policy

As a result of the recent discussion on edit filters and how they're used I've opened a section at the Village pump regarding the possibility of creating policies regarding the filter. Your opinions are welcome. Sam Walton (talk) 00:43, 26 June 2015 (UTC)

Page structure

I've made a few changes to the main page, moving the extended documentation off to its own page at Wikipedia:Edit filter/Documentation and updating this page to be more of an information page. I've added some information from recent threads on edit filters to steer it towards the current community consensus on how filters should be used. Your input is welcome and please feel free to change or expand the page. Sam Walton (talk) 19:42, 30 June 2015 (UTC)

It's worth considering broad parameters, perhaps, as guidance. For example "less than a few hits per week" would be worth an edit filter if it was a particularly bad issue and it was a very light weight filter. All the best: Rich Farmbrough, 02:36, 3 July 2015 (UTC).
BTW, the current changes look good. All the best: Rich Farmbrough, 02:41, 3 July 2015 (UTC).
Fair point, I've noted that that isn't a hard rule. Sam Walton (talk) 13:01, 3 July 2015 (UTC)

A false positive from an IP

https://en.wikipedia.org/wiki/Special:AbuseFilter/examine/log/12627707

Maybe we need to analyse this EF in a little more detail.

All the best: Rich Farmbrough, 14:58, 11 July 2015 (UTC).


651

I'd like to request some additional eyes on Special:AbuseFilter/651, a IP vandal targeted filter created by User:Callanecc six months that seems very broad (e.g. IP ranges with /11 and /12 and broad page categories). While there is some vandalism in there, the false positive rate seems pretty high for a full disallow filter. Also, given that it has been six months, is this particular vandal still active? The related SPI, Wikipedia:Sockpuppet investigations/AfricaTanz, hasn't been updated since December. Dragons flight (talk) 01:39, 28 June 2015 (UTC)

May I suggest we disable and see what happens? All the best: Rich Farmbrough, 21:54, 4 July 2015 (UTC).
 Done All the best: Rich Farmbrough, 00:39, 14 July 2015 (UTC).

OldPossibly outdated abuse filters

Could we disable 648? It only has ever had 140 hits, and seems to be obsolescent if not obsolete. All the best: Rich Farmbrough, 00:36, 14 July 2015 (UTC).

-revi seems to have only recently re-enabled it, implying that it might be needed. Sam Walton (talk) 00:38, 14 July 2015 (UTC)
I re-enabled it since I recently saw his patterns, so wanted to gather some log. I want to see it enabled (at least) until this Sunday. I'll disable it by myself this week or next week if no hit is found. — regards, Revi 14:20, 14 July 2015 (UTC)
Thanks! All the best: Rich Farmbrough, 15:10, 14 July 2015 (UTC).

User:Samwalton9: Can we disable 623 yet, if not can we temporarily disable 613? All the best: Rich Farmbrough, 15:10, 14 July 2015 (UTC).

@Rich Farmbrough: I spoke to MusikAnimal about that (for I think the second time, oops!) here. Sam Walton (talk) 16:24, 14 July 2015 (UTC)
If you look at the log for 613 (search for "diff") most of the edits that match 613 were stopped by 623. The oens that weren't seem to be universallymostly bad edits. All the best: Rich Farmbrough, 16:39, 14 July 2015 (UTC).


Filter 2

I propose that Filter 2 becomes a standard private test filter. It will allow us to test private filters privately, with out, perhaps, chewing through filter numbers quite so fast. All the best: Rich Farmbrough, 18:36, 17 July 2015 (UTC).

While I agree that a general test filter isn't a bad idea, it's not like we're in danger of running out of numbers. Sam Walton (talk) 21:25, 17 July 2015 (UTC)
For the last few months I've been reusing EF684 to combat short-term outbursts of vandalism, and have found it convenient to make the necessary changes to an existing filter instead of creating a new one from scratch. So as a counter-proposal, I'd like to propose that each EF manager should be allocated a small block (3, 5, or 10?) of consecutively numbered filters for this purpose, or for testing. A subpage of WP:EF would list who has which block of filters. Perhaps the publicly viewable filter description should include the owner's username, too. We could also agree that any of these filters would only be allowed to remain active for a month, say, after which they would be disabled unless proven useful for the long term, in which case they'd be moved into the main block (which should be the lower numbered filters: perhaps EF1-500).
  • Advantages: 1). It would be easier to see who's doing what. 2). It's untidy to leave so many dead filters lying around – even though there are plenty of numbers. 3). EF managers should feel more responsibility for their own filters, so might be quicker to fix them and to disable them when they're no longer needed.
  • Disadvantages: 1). Since the filters would get re-used, the link between the EF number and its purpose would be lost for these filters. 2). Some reorganisation of existing EF numbers would be needed to make best use of the proposal. 3). ... what's the elephant in the room that I haven't spotted?
 —SMALLJIM  22:30, 17 July 2015 (UTC)
  • Running out of numbers it's much easier to talk about and remember small numbers. We will be into 4 digits soon.
  • EF'ers prescribed a block of test filters I would have no objection if someone wanted to use one or two. I have considered it myself. But test filters shouldn't run for long, and the little numbers (starting at 1) are a good place to have them because we don't have to worry about them not running due to edit conditions/run time. All the best: Rich Farmbrough, 22:36, 17 July 2015 (UTC).
Re little numbers: it seems obvious to me that new untested filters should run at a lower priority than the important filters that have been proven to help keep the place clean.  —SMALLJIM  22:50, 17 July 2015 (UTC)
Do we know that the extension definitely runs through the filters starting at 1 and going through them sequentially? Sam Walton (talk) 09:24, 18 July 2015 (UTC)
Run order is never explicitly specified, and follows whatever order is returned by the database query used to select filters (with no ORDER BY directive). In practice, the default order in the database is probably the same as the creation order, and hence sequential, but there is no explicit guarantee. Dragons flight (talk) 09:39, 18 July 2015 (UTC)
Thanks. There is evidence that higher numbers run last, because the ones we see failing on condition limit always seem to be at the end. Indirectly many other queries are replied to with the oldest entries in the table first (e.g. "what links here" ). All the best: Rich Farmbrough, 19:25, 18 July 2015 (UTC).

Filter 31

From anonymous user: What's the point of this filter, why can't I find any details on WHY it filters, who made it and who decided it should be employed? I was filtered for trying to constructively argue on a TALK page!!! Why should a bot be allowed to exist on wikipedia that "filters" (it acts more like a fascist censor, apparently) when it includes no curse words or racial epithets? Or anything else stupid like all-caps texts or ASCII art or something like this? I wish I could find the author of this program and go "filter," of all of his edits! There was absolutely nothing wrong with my edit, or any bad words or anything like this. This own particular reply of mine on the talk page of this fascist bot isn't quite as level-headed but that's because I am very angry! Maybe this is how the old guard scares off potential new editors? — Preceding unsigned comment added by 75.132.236.51 (talkcontribs)

@Rich Farmbrough: Looks like a good number of talk page edits were disallowed when ::: was added to the ASCII art filter. I can easily see this as a simple mistake, but it was left like this for some time. All due respect, but please give due caution to filters that disallow, and always monitor filter hits after making such changes MusikAnimal talk 04:45, 25 July 2015 (UTC)
RF, you deserve a trouting – no, a sharking for that :-)  —SMALLJIM  09:46, 25 July 2015 (UTC)
Consider me trouted - or sharked as the case may be. All the best: Rich Farmbrough, 11:19, 25 July 2015 (UTC).

Filter test display oddness

There seems to be an issue in the names of articles as displayed on a the test page. Possibly one or more invisible characters, or non-breaking spaces instead of genuine spaces. Regardless cutting and pasting the names into the rules often doesn't work. We need to hunt this down and raise a bug. I'll do it eventually, but if someone else does it first, all the better. All the best: Rich Farmbrough, 11:19, 25 July 2015 (UTC).

Condition limit

@Dragons Flight, Zzuuzz, Samwalton9, and Smalljim: We are reaching condition limit for less that 1 in 1000 edits, but less would be better. Of course we have discussed asking to have this figure raised. But it occurs to me that there is may be a subtle way of avoiding it that lies in our hands. I use the word "condition" naively in the following discussion.

Every edit gets hit by every filter, so generating at least "n" conditions.

Many filters test for "newbie" status as the first condition, suppose for simplicity they all do. Then every "newbie" edit would get hit with "2n" conditions (minimum).

By reordering the conditions it may be possible to reduce the peak number, and reduce the proportion that hit the condition limit. Drawback: Overall efficiency would probably fall.

Comments?

All the best: Rich Farmbrough, 15:31, 19 July 2015 (UTC).

Do you mean reverse the normal practice, by having conditions like added_lines irlike some-complex-regex as the first line in the filter?  —SMALLJIM  16:20, 19 July 2015 (UTC)
Thing like that we generally put deep on the understanding that they are complex hence expensive and to be avoided. Obviously there are relatively simple regexen, and some are just "contains". Quite often a reasonably cheap alternative does exist. Ideally it should be non-compound of course. And we shouldn't change all, or we risk re-introducing a new variant of the same problem. It's unfortunate that
  1. Edit Filters don't provide statistics for each section's pass/fail
  2. We can't just work on average conditions
  3. There is no way to combine edit filters under overall conditions - like if condition X run filters y through z.
All the best: Rich Farmbrough, 18:42, 19 July 2015 (UTC).

If anyone wants to work at cutting conditions, the worst filter for conditions (I think) is Special:AbuseFilter/31 which can hit 70+ conditions. Large lists using contains_any rack up a lot of conditions, and it really should be converted to a regex. Dragons flight (talk) 23:06, 19 July 2015 (UTC)

I don't think RF's idea would be helpful on that filter, but more generally, looking at Example 2 at the end of mw:Extension:AbuseFilter/Conditions, if we were able to change test A from being a very simple but quite frequently satisfied test like we use now (the "newbie" test), to a relatively simple but very rarely satisfied test, then most edits would fail each filter at that first test, leading to fewer conditions being consumed per edit overall, at the expense of more processor time evaluating the necessarily more complex test A every time. The question is - is that a good trade-off?  —SMALLJIM  23:25, 19 July 2015 (UTC)
Sorry, I didn't mean that RF's suggestion needed to have anything to do with filter 31. I only meant that filter 31 could do with a revision to reduce its condition count. To answer the more general question: The current condition limit system creates some perverse incentives. The idea of making filters slower in a way that uses fewer "conditions" is an example of this. I think there is broad agreement among devs that we ought to switch to a runtime based limit system, though as yet no one has implemented that. Even in the mean time, I would suggest that even if front loading expensive checks would result in fewer conditions, that is still not a good design approach. Dragons flight (talk) 06:02, 20 July 2015 (UTC)
I agree it's not good design, but it could be argued that since the hardware has no doubt been upgraded since the abuse filter was first implemented, we might be less concerned about speed than we were. According to Wikipedia_talk:Edit_filter/Archive_2#Be_careful_about_load, there used to be a report on how much time the abuse filter was adding to the edit commit time. The link there is now dead. If there is a replacement report it would provide some useful information.  —SMALLJIM  09:31, 20 July 2015 (UTC)
Per filter conditions and run time are a sorely missed feature too. Sam Walton (talk) 09:50, 20 July 2015 (UTC)
The edit filter doesn't generate enough load to show up in the full cluster load monitoring (which is dominated by page rendering requests), and I'm not aware of any monitoring tools that are restricted to the editing process specifically. I've emailed a dev who should know though. Dragons flight (talk) 09:54, 20 July 2015 (UTC)
Any response? It would be useful if it could be shown that the resource usage was really tiny and could easily be increased. In my naivété, I assume that doubling the condition limit would be a simple matter of changing 1000 to 2000 in one line of code. After all, I suspect (without checking) that the original number was just chosen as something reasonable rather than an exactly calculated figure.  —SMALLJIM  12:26, 24 July 2015 (UTC)
I actually looked at the PHP today ( to determine the exact scope of "remspecials") and it seems very straightforward by and large. I didn't locate the condition limit, but I suspect it would not be hard to find. All the best: Rich Farmbrough, 23:35, 24 July 2015 (UTC).
You're looking for $wgAbuseFilterConditionLimit = 1000; in AbuseFilter.php. That said, I think it would be better to replace it with a time limit rather than a condition limit. Dragons flight (talk) 12:41, 25 July 2015 (UTC)
31 can be simplified. And again there may be "perverse" benefits by matching a regex instead of a list of strings. Or not so perverse, because the list of strings may have a 2 PHP function call overhead per string. All the best: Rich Farmbrough, 23:35, 24 July 2015 (UTC).
"Two"? That would be wishful thinking. Handling each parameter in a function list involves upwards of 20 function calls because the whole expression evaluation chain is applied to each parameter before concluding that it is just a string. (This is one of the areas where there is serious potential for making the PHP software smarter.) Dragons flight (talk) 12:41, 25 July 2015 (UTC)

Review of hidden inactive 714 prior to enabling

Just added hidden Special:AbuseFilter/714 but this is my first filter; would appreciate review and comment prior to activation. It passed the parser checker etc. Thanks. Georgewilliamherbert (talk) 19:39, 27 July 2015 (UTC)

Looks fine to me, I made some minor optimisation changes to the ordering (I think there are less edits to that page than by new contributors), and to the bracketing because of the less than clear way that filters operate. I've enabled it for testing :) Sam Walton (talk) 19:47, 27 July 2015 (UTC)
Right. I was more focused on not screwing up the syntax but that's an obvious improvement on performance impact. Thanks! Georgewilliamherbert (talk) 20:01, 27 July 2015 (UTC)
Ok, it caught a real hit and logged it, after hours of nothing. I am assuming it's working OK and armed it with the block-edit bit on now. Georgewilliamherbert (talk) 23:02, 27 July 2015 (UTC)
Nice work! You had a genuine block too. All the best: Rich Farmbrough, 23:25, 29 July 2015 (UTC).

688

Filter 688 isn't working: it should block certain edits to User talk:Mike Rosoft and when run in test mode [1], it shows hits, but it isn't logging or preventing them live. What's wrong, or what am I doing wrong?  —SMALLJIM  15:49, 29 June 2015 (UTC)

I have had a quick look and it's not obvious to me, if that's any comfort. All the best: Rich Farmbrough, 02:32, 3 July 2015 (UTC).
Thanks for the reassurance. The vandal hasn't been back yet (AFAICT) to allow me to see if it's still a problem, but the condition limit issue is the only explanation that I can think of.  —SMALLJIM  18:18, 3 July 2015 (UTC)
We've had this issue before, the likely culprit is the condition limit. Sam Walton (talk) 19:27, 3 July 2015 (UTC)
Condition limit is an issue we should take up with the devs, I think. The average conditions is probably fine, but IP's and unconfirmed hit almost every filter. We can tweak a few more conditions out of what we have and reduce the active filters by a few, probably, but we really need something that considers the load of the edit filters as a whole. All the best: Rich Farmbrough, 21:57, 4 July 2015 (UTC).
What we could really do with is a replacement for the per filter condition stats. They were removed a few months ago with the promise of something better coming along, but currently we have almost no idea which filters are behaving poorly. Sam Walton (talk) 22:04, 4 July 2015 (UTC)
I guessed that was what happened. It's a bad measure anyway, and we should ask for more conditions/time.

──────────────────────────────────────────────────────────────────────────────────────────────────── For example:
<very unlikely to be true cheap condition> & (

"foo" in lcase added_lines &
!"foo" in lcase removed_lines

) might well be efficient but it counts as two conditions (AIUI) one for the condition and one for the parenthesis. Conversely the awful:
"foo" in lcase added_lines &
!"foo" in lcase removed_lines

also (again AIUI) counts as two conditions.
All the best: Rich Farmbrough, 00:54, 14 July 2015 (UTC).

Your code sample isn't valid. lcase is a function, so the correct version would be:

"foo" in lcase( added_lines ) &
!"foo" in lcase( removed_lines )

Which is in fact 6 conditions. Dragons flight (talk) 10:45, 20 July 2015 (UTC)
Sure but the point remains; a correctly optimized version of the first example could be executed in a machine cycle (or part of one) where as "foo in added_lines" could take many thousands or even hundreds of thousands. All the best: Rich Farmbrough, 21:37, 2 August 2015 (UTC).

Grawp/Hagger

Take a look at wikt:Special:Contributions/Glory_of_Space. I am curious if Wikipedia has found it fruitful to write an edit filter against this vandal; if so, can Wiktionary copy that filter? (People like bd2412 and Thryduulf are admins on both sites and could presumably copy the filter over if it is private.) I wouldn't necessarily turn it on on Wiktionary unless the vandalism becomes a repeat problem, but it seems like a good idea to have it at hand. -sche (talk) 20:13, 28 July 2015 (UTC)

Interesting question about filters. Our filters are CCBYSA4.0 I suppose... Face-smile.svg In general sharing filters with en:Wiktionary is unlikely to be a problem, per se, I did immediately worry about our private filters eventually leaking from relatively mature projects to less mature, and maybe less well run projects - though of course we have had our share of leaky functionaries - and hence into "the wild".
I wouldn't object to either of the above named copying filters across. What do others think? All the best: Rich Farmbrough, 23:25, 29 July 2015 (UTC).
Heh, I hadn't even considered licensing — I meant "can Wiktionary copy that filter" in a "does anyone mind" way. :b But looking at your filters' names, I haven't spotted any that are specific to this user. However, I would be interested in a copy of 68 (Pagemove throttle for new users). We could certainly keep the filter private. -sche (talk) 02:11, 30 July 2015 (UTC)
There's no issue with copying filters over to other wikis :) Sam Walton (talk) 10:41, 30 July 2015 (UTC)
@Thryduulf: - could you copy filter 68 to Wiktionary? All the best: Rich Farmbrough, 21:40, 2 August 2015 (UTC).
@-sche and Rich Farmbrough:  Done as Wiktionary filter 44. I have not copied the warning template (MediaWiki:abusefilter-warning-badmove) and have set it to tag only at the moment. Active Wiktionary admins can do the rest based on consensus there (I'll post on the Grease pit too). Thryduulf (talk) 22:51, 2 August 2015 (UTC)Fixing ping and resigning so that works Thryduulf (talk) 22:52, 2 August 2015 (UTC)
Thanks! All the best: Rich Farmbrough, 23:24, 2 August 2015 (UTC).
Thank you! :) -sche (talk) 23:34, 2 August 2015 (UTC)

Youtube links

It would be nice to have some standard wordings for this common "false positive".

I would like to achieve the following goals:

  1. Thank the editor for their contribution
  2. Indicate why Youtube links are generally not a good idea
  3. Indicate which bad category this link falls into if any.
  4. Explain the next step to the editor possibly:
    1. Post the information without the link
    2. Offer to post, or confirm that we have posted the link on their behalf
    3. Suggest uploading the video to Commons with OTRS release (if it's their own)
    4. Where to turn to for alternative references

All the best: Rich Farmbrough, 12:53, 5 August 2015 (UTC).

{{EF}}

Make linking easy using {{EF}} - e.g. {{EF|364}} Filter 364. All the best: Rich Farmbrough, 18:52, 6 August 2015 (UTC).


Unhiding filters

The following is a complete list of the active hidden filters:

Of these, I would suggest that the argument for hiding the filter isn't very strong for the following ten cases.

Most of these do pretty much what you'd expect based on the short description, so one can mostly guess what the filter is doing even though the details are hidden. In the spirit of openness, I tend to think that filters shouldn't be hidden unless there is a good reason to think that specific vandals will use knowledge of the filter code to deliberately defeat them. So, I'd like to suggest that we unhide these ten filters. However, I wanted to seek second opinions before doing so, as well as let other people look at the list of hidden filters in case there are other examples where hiding the details is probably not accomplishing much. Dragons flight (talk) 01:16, 28 June 2015 (UTC)

Thanks for this list Dragons flight. I've un-hidden 697, I don't know why I made it hidden in the first place, there's really no need. Sam Walton (talk) 19:07, 30 June 2015 (UTC)
I've BOLDly unhidden 126 (Youtube) since I was wondering about that one myself. I think 559 I would be wary of (although I am on archive.is's side!) because we know that significantly resourceful people tried to add these links. All the best: Rich Farmbrough, 01:58, 3 July 2015 (UTC).
I would recommend caution about disclosing 68, and recommend filter 464 for unhiding. Filter 271 I think should remain private at this time as these bots and hackers are mischievous devils. -- zzuuzz (talk) 13:14, 3 July 2015 (UTC)
I marked 68 "not done" as it combats long-term abuse. The other throttle filters may have the same rationale. All the best: Rich Farmbrough, 12:40, 14 July 2015 (UTC).
There's a few more mindless vandalism ones that could potentially be made public.
All the best: Rich Farmbrough, 00:40, 14 July 2015 (UTC).

I just created hidden Special:AbuseFilter/714 and believe it should stay that way but open to independent review. Georgewilliamherbert (talk) 19:37, 27 July 2015 (UTC)

 Done All the best: Rich Farmbrough, 18:55, 6 August 2015 (UTC).

Variable names

There appears to be a bug disallowing variable names starting with "ex". Perhaps "ex" has a special meaning, possible related to numbers "9.53ex8"?

Even if it does still looks like a parse bug to me. All the best: Rich Farmbrough, 19:18, 6 August 2015 (UTC).

364

I see a ton of the changing of names in BLP infoboxes. I'm not sure what 364 is tagging (Special:Tags doesn't list any, possibly possible libel or vandalism?), but I see a ton of vandalism of this sort. I'm not sure of how the filter is written, but it doesn't seem to be hugely effective, and it's certainly needed. If anybody could take a look at it it would be great. Kharkiv07 (T) 19:43, 5 August 2015 (UTC)

@Kharkiv07: Could you provide some examples of edits which should have been caught by this filter? Sam Walton (talk) 19:48, 5 August 2015 (UTC)
Yea, I'll have time in an hour or two. But I think I may have found the problem, does it cover infoboxes like Template:Infobox sportsperson, Template:Infobox politician, Template:Infobox writer, etc? I think this may be the downfall. Regardless, I can get some when I have a moment later today. Kharkiv07 (T) 19:58, 5 August 2015 (UTC)
@Kharkiv07: I'll drop you an email with the filter specifics, not going to post them here but I don't expect you're going to use the information to destroy the encyclopedia. Sam Walton (talk) 20:04, 5 August 2015 (UTC)
I've certainly seen more, but I haven't quite been able to track a ton down; here are a few examples of ones that haven't been tagged:
  • [2]
  • [3]
  • [4]
  • [5]
Without doubt I can find you more, thanks for your help. Kharkiv07 (T) 21:06, 5 August 2015 (UTC)
I can definitely pinpoint all of those to a particular condition in the filter, but I can see why that condition is there; there'd be a whole ton of false positives without it. I'll have a think. Sam Walton (talk) 21:18, 5 August 2015 (UTC)
Since this is not a "disallow" filter, careful widening of its scope seems worthwhile. The amount of FP can be monitored. All the best: Rich Farmbrough, 17:56, 6 August 2015 (UTC).
There's a way we could improve this filter but it requires a feature that the AbuseFilter may or may not currently have. I'd still be careful with this filter since it tags with "possible libel or vandalism". Sam Walton (talk) 21:24, 6 August 2015 (UTC)

Edit filter guideline draft

Hi all. Newyorkbrad has started a draft for creating a guideline or policy to place on WP:EF in response to ArbCom's encouragement that a guideline or policy should be formed for edit filters' use. Please review Wikipedia:Edit Filter/Draft and alter/comment as you wish. I think the idea is to form a solid draft between the edit filter managers and interested community members before taking it to a proper RfC. Sam Walton (talk) 09:45, 10 August 2015 (UTC)

Instruction creep. All the best: Rich Farmbrough, 12:23, 10 August 2015 (UTC).
I'd like to set this up as a guideline, I agree that a strict policy for edit filters wouldn't be helpful, but a guideline would be useful to have. Sam Walton (talk) 12:53, 10 August 2015 (UTC)
Pinging likely interested editors: @MusikAnimal, Od Mishehu, Dragons flight, Reaper Eternal, and Zzuuzz: Sam Walton (talk) 11:20, 13 August 2015 (UTC)

Filters 613 and 623

Just a heads up that with the latest update to MediaWiki [6], these are no longer effective. The latter, originally intended for long-term abuse, might still be useful but we'd need someone to keep an eye on it to ensure it's targeting who it's supposed to, as the hit count is going to be considerably low. Pinging original author NawlinWiki MusikAnimal talk 20:22, 14 August 2015 (UTC)

Edit filter noticeboard

As part of our efforts to improve the use of the edit filter, an edit filter noticeboard has been created. We hope that this will be a better venue for users to discuss and ask questions about edit filters, whilst also freeing up WT:EF for discussion of the corresponding project page. Sam Walton (talk) 15:39, 18 August 2015 (UTC)

Filter 31 false positives

Special:AbuseFilter/31 There have been a couple of false positive reports recently about this filter, which is supposed to block ASCII art, blocking edits to math formulas. I don't know if this was maybe caused by recent edits, or the problem was always there. Examples: Special:AbuseLog/12875270, Special:AbuseLog/12876144. Someguy1221 (talk) 22:52, 17 August 2015 (UTC)

Pinging Slakr, unsure if the recent change had anything do with this MusikAnimal talk 01:20, 18 August 2015 (UTC)
I tested the prior version of the filter and found that it didn't match the math edits, so clearly the issue was created by the recent attempt to convert this to regex. I've reverted to the old version for now. The conversion to regex is still a good idea because the old approach uses a very large number of conditions, but obviously we need to figure out the bugs. Dragons flight (talk) 07:09, 18 August 2015 (UTC)
I've been thinking about this filter since the first report of its large condition count, and without saying too much, it seems that something along the lines of ^\s+ would be a useful test under which to group the matches for multi-line graphics, such as the original goatse. A lot of the conditions in this filter appear to be targeted at multi-line graphics and, looking at recent hits, these don't seem to be attempted much these days. A change like this would dramatically reduce the average condition count.  —SMALLJIM  09:55, 18 August 2015 (UTC)
Yup, my bad. For some reason, the regex version matches on those math edits but not when testing when I stick it in preg_match() w/ u enabled (for example). I'm guessing this is an additional escaping level problem with the backslashes. In my defence, I did ensure they'd match the current matches (and ran the last-100 a few times), but apparently none of the math edits were in any of those runs. :P I'll look into this. Sorry for any annoyance. --slakrtalk / 15:52, 18 August 2015 (UTC)

Help request

Hey all,

Can someone who knows how to use edit filters reply at User talk:Technophant#Requesting editing privileges for WP:AN and my userpage please? Thanks, Mdann52 (talk) 07:56, 20 August 2015 (UTC)

Revoking the user's autoconfirmed status

I've never seen this feature used before. Is there consensus against using it? MusikAnimal talk 19:22, 23 August 2015 (UTC)

I think we would need a proper strategy. For example for certain egregious vandalism it would make sense to knock the account back to unconfirmed, so that future edits were more closely scrutinised. However most of those suitable-for-knock-back filters might not catch established accounts anyway, and we would want to work out which EFs should be included in the closer scrutiny. All the best: Rich Farmbrough, 01:50, 25 August 2015 (UTC).

Filter 716

Further to Wikipedia:Edit_filter/False_positives/Reports/Archive_42#160.39.2.162, filter Filter 716 should stop this sort of situation arising. Any comments? All the best: Rich Farmbrough, 23:24, 2 August 2015 (UTC).

Interesting. I'm curious to see how many hits 716 gets. Sam Walton (talk) 23:34, 2 August 2015 (UTC)
I would have thought a tiny number. It's one reason I'm cautious about it. However I really don't like that a filter stopped a good faith vandal revert. All the best: Rich Farmbrough, 14:25, 3 August 2015 (UTC).
A surprising 8 in 4 days. I have set it to disallow. All the best: Rich Farmbrough, 17:43, 6 August 2015 (UTC).
Are you trying to target only the addition of the GA/FA tags? You may want to define an edit_delta, then. I'm guessing with this hit the user copied/pasted an existing article as a "template" for the one they were trying to create, unknowingly also copying the GA template. MusikAnimal talk 16:12, 8 August 2015 (UTC)
I've moved this back to log-only as we're getting false positives. With this edit the user was trying to undo vandalism but was unable to. And here a user made what appears to be an innocent test edit and tried to undo their mistake but couldn't. I've also set the edit_delta to less than 100, as many of these are not users tagging article as FA/GA, but rather copying and pasting another article that happened to be a FA/GA. This is presumably not what this filter is for, and besides such copy and paste moves are either caught by other filters or quickly reverted as obvious test/vandalism. In my opinion this filter should not disallow unless it can be ensured to catch what we truly want, and if it is currently doing that we should come up with a more fitting name. Either way, please keep a close eye on filters that disallow... MusikAnimal talk 13:18, 17 August 2015 (UTC)
This edit should have been stopped, maybe I need to include that in this filter.
The motivating edit was someone cut-and-pasting a good article over an exisitng article, and a new user was unable to revert, because Filter 365 stopped them. All the best: Rich Farmbrough, 03:31, 29 August 2015 (UTC).

Question

Is there a way to block someone from using the term "Paul Easter" in an article? This is a bit tricky, but long story short there's a guy that has been trying to make an article for himself for the past year. He's made over a hundred sockpuppets, which you can look over here. By large these articles have been easily detected and deleted, but it takes up a lot of time and energy. McGeddon has requested a block on article titles with this name, but sometimes Easter will deliberately leave his name out of the title in an attempt to avoid detection. Is there anything that can be done with this? There's another person by the name of Paul Easter so there's likely not much that can be done, but I figure it's worth it to ask. The guy is pretty persistent and to be honest, I kind of see him as someone that will probably keep this up for a long while. Tokyogirl79 (。◕‿◕。) 09:30, 7 September 2015 (UTC)

Yep. Filter 726 should be tracking this. Will set to disallow if it works. Sam Walton (talk) 10:34, 7 September 2015 (UTC)
See Filter 58. NawlinWiki has been dealing with this for years since early 2014.  —SMALLJIM  10:44, 7 September 2015 (UTC)
Ah, wasn't aware. Won't that catch mentions of the Paul Easter we have an article on though? It also wouldn't flag the times he doesn't write "Paul Easter" but rather Paul T T Easter or the like. Sam Walton (talk) 10:49, 7 September 2015 (UTC)
You'd have to look through the history of EF58 to see the full story, hence my ping to NW, who could no doubt explain further. The real point is that he's been a minor nuisance for a long time and continues to be so despite efforts to stop him. It's become a game for him, I think, and we continue to play along because we have no alternative.  —SMALLJIM  11:09, 7 September 2015 (UTC)
Looks like this is working, he's been creating articles which clumsily refer to him as "Paul E'aster" or just "Paul". Could really do with that Wikimedia title blacklist request being sorted out, though. (It was set up in February but is only blocking usernames, not article titles.) --McGeddon (talk) 09:33, 8 September 2015 (UTC)
  • I have a sinking feeling that this will likely end up being one of those instances where we have to reach out to an Internet company, like they did with BambiFan01. I'd say that I'd wonder if he's put forth this much effort in promoting himself elsewhere, but I'd cringe to think of him being unleashed on some poor magazine or website company. Tokyogirl79 (。◕‿◕。) 10:08, 8 September 2015 (UTC)
  • Has anyone tried speaking to him? Sam Walton (talk) 10:18, 8 September 2015 (UTC)
  • Sort of. I tried reaching out to the editor at the talk page for the now deleted entry that went through AfD and there was some interaction at the AfD itself via his sockpuppets. I'm not sure how to put this, but if his actions at the AfD were a little more well... sane, I'd try contacting him IRL via e-mail or something, but his actions at the AfD didn't really show that it'd really be of any use. His response to having his page AfD'd was to open up all of the sockpuppets and then when it became obvious that deletion was imminent, he began saying that it was all part of a campaign to raise awareness for himself, that he was playing us all, and that he was going to make a movie about all of this. To be very blunt, I received some major red flags that suggested that interacting with him in a way that might allow him to identify me IRL would not be a very safe thing to do. He's already received enough information to where he should be fully aware of Wikipedia's policies. I don't think that talking to him IRL would really accomplish much. Tokyogirl79 (。◕‿◕。) 10:46, 8 September 2015 (UTC)
  • He's also had various people talk to him about the various issues (sockpuppetry, editing in general, etc), such as Ruby posting this at User_talk:Housefullofcards#Multiple_accounts, and I also reached out to him on his userpage here for the Paul Easter account. Tokyogirl79 (。◕‿◕。) 10:48, 8 September 2015 (UTC)
  • I'm also unsure as to how we'd contact him even if we wanted to, since most of his social media accounts are inactive and he doesn't appear to have any personal websites. I'm also not sure which, if any, of the e-mails he used for Wikipedia would be active. So aside from concerns about personal safety, there's also the question of even if we'd be able to contact him if we wanted to. Tokyogirl79 (。◕‿◕。) 10:50, 8 September 2015 (UTC)

Edit filter guideline draft

Just a reminder that there is currently work ongoing to create a guideline for edit filter use. Please feel free to improve it and/or join in discussions at the talk page. Sam Walton (talk) 15:00, 9 September 2015 (UTC)

RfC: Edit filter guideline

Editors are invited to join a Request for Comment regarding the introduction of a proposed guideline for edit filter use. Please join the voting and discussion at Wikipedia:Edit filter/RfC. Sam Walton (talk) 17:24, 17 September 2015 (UTC)

Request for Permission: samtar

Hi all - I'd like to request the edit filter manager permission.

  • I'm a BSc Computer Science graduate with experience in regex
  • I've been a member of Wikipedia for 7 years, with no blocks or any sanctions, and am a trusted user.

Although I've only recently found out about WP:FLTR, I am really keen to help the project. For a long time I assumed something like this existed while patrolling pages and noticing tags such as "CSD removed" etc. I'd like to now put my experience to good use. Thanks for your consideration. samtar (msg) 08:56, 18 September 2015 (UTC)

Hello and thank you for your eagerness to help. The edit filter is a highly specialized tool that is among the most powerful the wiki has to offer. I don't doubt that your technical know-how is genuine, but this user right is reserved for those who have a specific need for it and/or have significant trust from the community. Not having the right doesn't mean you can't help, though! There is a backlog of requested edit filters where we welcome your input and aid in constructing regex for the filters. There is also the edit filter noticeboard for generalized discussion on the tool should you like to be more involved. Regards MusikAnimal talk 02:20, 19 September 2015 (UTC)
Hi MusikAnimal, thanks your your reply. I completely understand, and I'll start helping out where I can. Thanks! samtar (msg) 09:27, 19 September 2015 (UTC)

Article history link in Edit filter log?

Hello, I am regularly checking the deadlink spam filter and noticed a handling problem with "Edit filter logs" like [7]. In probably half of the cases one can easily guess, if the addition was a spam link. In those cases the main question of interest would be: is the spam link still present in the article or has it been removed by someone else? But there is no direct history link to get that article information without clicking through other pages first. 1) Would it be possible to add a link to the article's history for each entry? 2) Who needs to be asked for such a change? Thanks for any feedback and advice. GermanJoe (talk) 15:22, 24 October 2015 (UTC)

@GermanJoe: I'm not sure if I follow you. But moreover, you might want to move this to the edit filter noticeboard, which is the new home for this sort of discussion. This talk page is now reserved for discussing the guideline. Best MusikAnimal talk 16:13, 24 October 2015 (UTC)
I knew, I was missing something (but not what exactly obviously). I'll copy it there and try to clarify, thank you. GermanJoe (talk) 16:18, 24 October 2015 (UTC)

Requiring a public notification for filters set to disallow

During the recent RfC, a suggestion was made that edit filter managers should publicise that they created, or will create, a filter set to disallow edits. Davidwr proposed the following wording: "Except in urgent situations, edit filters must not be set to disallow without thorough testing and a notice to other edit-filter reviewers to give them time to review the filter for technical accuracy. In urgent situations, the notice may be made after-the-fact. Prior to and during the review of an edit filter which is set to "disallow" due to an emergency, the editor placing the edit filter is responsible for seeing that the logs are regularly monitored and false positives are minimized."

I like this idea a lot, I think one of the major issues editors have with the edit filter is how it's obscured within Special pages; posting a note to EFN stating that Filter X will be set to disallow after a week of testing gives everyone a heads up and allows other EFMs to help out and double check it prior to switching the disallow button, and gives the community an opportunity to voice their opinions. I wouldn't want this to compromise the filter's usefulness, so if non-EFMs/admins wanted to discuss the contents of a hidden filter, they can contact the mailing list wikipedia-en-editfilters for details (if a user in good standing).

I think the above wording is pretty good (I'd only want to make trivial alterations like explicitly naming the venue as EFN and mentioning the mailing list as I did) and I'd like to have a discussion about it before proposing it properly (RfC?); what are your thoughts? Sam Walton (talk) 12:24, 17 November 2015 (UTC)

I agree. Barring an emergency it's sensible to get feedback before setting a filter to disallow. For private filters do you think EFMs should get notice if a filter is set to disallow? Perhaps just send out a notification via the mailing list?
Another question is what if the filter had been set to disallow in the past without concern, and was later disabled. Then we want to re-enable as the disruption has resumed. Do we need to seek approval again? I would say probably not, unless there are other modifications aside from simply re-enabling it MusikAnimal talk 17:25, 17 November 2015 (UTC)
I think we can trust EFMs to watchlist EFN, so I don't think a mailing list notification is necessary. I agree that we don't need to seek re-approval for something which has been uncontroversially disabled due to inactivity. Sam Walton (talk) 18:11, 17 November 2015 (UTC)

RfC

After nearly a month open and no conversation relevant to the RfC in well over a week, I believe sufficient consensus exist to enact the change. Kharkiv07 (T) 15:59, 12 December 2015 (UTC) (non-admin closure)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should the following text be added to the 'Recommended uses' section?

Except in urgent situations, new edit filters must not be set to disallow without thorough testing and a notice at the noticeboard to give other edit filter managers and the community time to review the filter for technical accuracy and necessity.[1] In urgent situations, the notice may be made after-the-fact. Prior to and during the review of an edit filter which is set to "disallow" due to an emergency, the editor placing the edit filter is responsible for seeing that the logs are regularly monitored and false positives are minimized.

References

  1. ^ Non-admins in good standing who wish to review a proposed but hidden filter may message the mailing list for details.
  1. Support as proposer. Sam Walton (talk) 22:46, 18 November 2015 (UTC)
  2. Support Seems very reasonable to me. For one it keeps the community informed about such powerful changes that could potentially effect them, but also the added review will help ensure stability of the filter and reduce the risk of false positives MusikAnimal talk 22:59, 18 November 2015 (UTC)
  3. Support Disallow is the nuclear option. While necessary in certain cases, it should only be used with caution and deliberate care. --Jayron32 23:48, 18 November 2015 (UTC)
  4. Support per Jayron; something this powerful needs to be made known. —⁠烏⁠Γ (kaw) │ 04:59, 19 November 2015 (UTC)
  5. Support seems reasonable. Hmm, somehow these words seem vaguely familiar Face-smile.svg davidwr/(talk)/(contribs) 02:57, 21 November 2015 (UTC)
  6. Support per MusikAnimal. Also, I wouldn't want a new editor to be confused and discouraged from editing unneccesarily. Recruited by legobot --I dream of horses If you reply here, please ping me by adding {{Ping|I dream of horses}} to your message. (talk to me) (My edits) @ 04:39, 21 November 2015 (UTC)
  7. Support reasonable notice and exception. — xaosflux Talk 14:11, 21 November 2015 (UTC)
  8. Support - filter editors are trusted users, but this sounds like a sensible precaution to minimize unnecessary risks. GermanJoe (talk) 15:34, 21 November 2015 (UTC)
  9. Support per MusikAnimal. — JJMC89(T·C) 05:31, 26 November 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comments

I am concerned that this will have a bad effect on filters designed to stop persistent vandals who do not necessarily rise to the level of LTA (yet). All the best: Rich Farmbrough, 20:44, 29 November 2015 (UTC).

Please clarify. Also, are there ways to tweak the proposal that would address your concerns? davidwr/(talk)/(contribs) 22:31, 29 November 2015 (UTC)
@Rich Farmbrough: I'd also be interested in hearing why you think this is the case. Sam Walton (talk) 08:43, 3 December 2015 (UTC)
The requirement when a persistent vandal is identified is to establish, if possible, a set of rules that will capture their edits and prevent them, and if not a set that will prevent a significant proportion of them, or log them with relatively few false positives.
It is important psychologically to be effective early on, both to deter the vandal and to support those combating them.
Discussing the EF provides traction both practically and psychologically for the vandal.
All the best: Rich Farmbrough, 23:57, 3 December 2015 (UTC).
@Rich Farmbrough: The guidelines about not discussing hidden filters in public would still apply. This wording only requires a user to post "I plan to set Filter X to disallow"; if the filter is for an LTA and hiddenit shouldn't have identifying info in the title and so they should be none the wiser. It might be worth noting, as for non-admins, that if users which to discuss the specifics, and not in the filter's notes box, that it should take place on the mailing list, though I'd hope that much is obvious from the rest of the guideline. Sam Walton (talk) 16:52, 6 December 2015 (UTC)
I think that covers my concerns. All the best: Rich Farmbrough, 19:54, 6 December 2015 (UTC).

See also phab:T62588 (Provide ability to watch for changes on filters). Helder 13:35, 6 December 2015 (UTC)

@He7d3r: It would be nice to be able to watch for private filter changes. For public changes a watchable page is generated at User:MusikBot/FilterMonitor/Recent changes, and there's also the formatted template {{User:MusikBot/Filter changes}}. If WMF makes a way to watch for changes they need to pay me for my bot work =P MusikAnimal talk 20:07, 6 December 2015 (UTC)
Note the bot flag isn't used when the bot writes to that page in particular, so it will still show up if your watchlist is set to hide bot edits. I'm also going to change the edit summaries to be more informative and link to the specified filters. This is all assuming WMF won't be quick to implement phab:T62588 MusikAnimal talk 20:48, 6 December 2015 (UTC)
Hey MusikAnimal! Thanks for the links!
Would your bot also work for Portuguese Wikipedia? I would be very interested in having a page to watch for changes to ptwiki's filters. Helder 01:53, 7 December 2015 (UTC)
@He7d3r: Should be no problem. I'm guessing the bot policy there is similar to here, where if the bot only writes to it's own userspace approval is not needed? Also I might need some help with translations MusikAnimal talk 02:38, 7 December 2015 (UTC)

Filter 742

I naively thought this filter would stop IPs like 81.158.98.222 (talk · contribs), but it didn't. Why? Please fix if you can. Other means won't help - the socker launches a java script to spam talk pages from a preloaded list, and then hops to another IP within a vast and busy IP range. One batch of their edits occurs within a short time (limited only by software). Materialscientist (talk) 04:49, 29 December 2015 (UTC)

@Materialscientist: It should, do you have an example of where it didn't? I notice the condition limit hit rate is somewhat high, which could be related, and should be fixed. Prodego talk 05:19, 29 December 2015 (UTC)
Condition limit was set by someone else, and I can't find a log of this change. Er, sorry the filter didn't fail, as it was set up only recently. My bad. Materialscientist (talk) 05:32, 29 December 2015 (UTC)
@Materialscientist: can you go hunt down the IPs who have been hit by this filter? Looks like some collateral damage, including unblock requests. You would be better able to tell who the target was. Examine their edits in the log and restore and reply as needed. I'll modify the filter to avoid this. Prodego talk 06:17, 29 December 2015 (UTC)
I know, I know, the filter blocks everything, and you can try to set a condition on added lines, but I bet the socker will bypass it on 2nd-3rd try. The unblock request should be redirected to those who rangeblocked parts of the targeted range - blocks were not in my plan, they are useless in this case and indeed cause much collateral damage. Materialscientist (talk) 06:22, 29 December 2015 (UTC)
One thing must be fixed in the filter though. I haven't figured out (upon a quick look) how to select only user talk namespace. The filter shouldn't act on IP talk pages. Materialscientist (talk) 06:26, 29 December 2015 (UTC)
I set the rate limit option to try to mitigate. Check out the settings and let me know what you think. FYI I meant "you'd be better able" not "you'd better be able" above, damn tablets! Prodego talk 06:28, 29 December 2015 (UTC)
Added the feature to ignore ip talk pages. Prodego talk 06:36, 29 December 2015 (UTC)
No native way to differentiate user_talk for a registered user or an ip; you go regex the page title to look for the ip pattern. — xaosflux Talk 15:13, 29 December 2015 (UTC)
@Xaosflux: Au contraire! What I have added was ip_in_range(article_text,"0.0.0.0/0"). Although underneath it all I'm sure it is what you suggest. Prodego talk 15:22, 29 December 2015 (UTC)
Slightly different, that is looking for edits from ip editors, not edits to user_talk's associated with ip editors - but if it works for what you are trying ok :D — xaosflux Talk 17:49, 29 December 2015 (UTC)
Normally it would be used in conjunction with the username to do that, but it is a generic two argument function, so as written it will detect if the page being editing is an IP talk page (when combined with the namespace check). Prodego talk 02:26, 30 December 2015 (UTC)

Edit filter for inappropriate "barnstar" messages?...

As per this current discussion at ANI, I'm wondering if an Edit filter could be created to prevent the addition of inappropriate and back-door personal attacking "barnstar" messages to user Talk pages? And the ANI case isn't the only recent example of this – an inappropriate "barnstar" was recently removed from my own Talk page by Kharkiv07. So, can anything be done about this?... TIA. --IJBall (contribstalk) 17:02, 30 December 2015 (UTC)

@IJBall: It could. What are the usual posts? I'm seeing the two kinds posted at ANI and your talk page, any more examples or is it usually these two? Sam Walton (talk) 18:24, 30 December 2015 (UTC)
@Samwalton9: Those are the only two I am aware of, but I've gotten the impression that various Admins have been dealing with this kind of thing a fair amount recently, so I suspect other Admins might know of some other examples. --IJBall (contribstalk) 18:28, 30 December 2015 (UTC)
I believe there's been three types recently.[8][9][10]. See also Category:Wikipedia sockpuppets of FiveSidedFistagon and Category:Suspected Wikipedia sockpuppets of FiveSidedFistagon. -- zzuuzz (talk) 18:57, 30 December 2015 (UTC)
@IJBall: Tracking at Special:AbuseFilter/745 Sam Walton (talk) 19:23, 30 December 2015 (UTC)

Abuse log; filter 550

Two of my edits (to Binomial theorem and Tyler Ward) have tripped filter 550, which has the description "nowiki tags inserted into an article".

Based on the information at Help:Wiki markup, nowiki tags break or stop the parsing of wiki markup.

I fail to see what is wrong with having nowiki tags, unless someone maliciously adds a nowiki to something that needs to be parsed as wiki markup, such as a bunch of links or an infobox.

I guess my beef about the whole thing is that the page where you can look at all the times when a user has tripped a filter is Special:AbuseLog. The use of the word "abuse" conveys that the user is doing something he shouldn't be doing and that edits that trip filters are bad.

And what is the purpose of the nowiki filter anyway? Vandalism through use of nowikis seems very rare; in my year plus of editing experience I have yet to see people vandalise with nowikis.

Thank you,

Bad Weather 2014 My workWhat's wrong? 13:59, 24 December 2015 (UTC)

@Bad Weather 2014: The extension being used here is called AbuseFilter because it was originally designed to prevent abuse. You'll notice the pages on the English Wikipedia now refer to it as the Edit Filter because, as you point out, it is useful for tracking all sorts of edits that aren't necessarily 'abusive'; as such it was renamed where possible to the Edit Filter some time ago. It's unavoidable, however, that the interface still refers to itself as the Abuse Filter, with an Abuse Log, etc. As for Filter 550, this is simply tracking for convenience and is not a filter designed to track 'abuse'. I'm not entirely certain why it was first created, but I'm aware that this filter was used for a long time to track Visual Editor errors (VE uses nowiki tags to make sure that the article ends up looking exactly how it does in the VE edit window, but it used to be a bit over eager in adding such tags). Not sure if it is being actively tracked by anyone now, but you can be sure that it isn't primarily for tracking vandalism. Sam Walton (talk) 14:19, 24 December 2015 (UTC)
*Samwalton9: Thank you for your response.
I have never used VisualEditor, but I understand.
If VisualEditor used to be overzealous in adding nowiki tags, meaning it isn't now, why do we still have the filter? -- Bad Weather 2014 My workWhat's wrong? 14:29, 24 December 2015 (UTC)
Not sure to be honest, since this isn't one of the filters I pay attention to. Sam Walton (talk) 14:43, 24 December 2015 (UTC)
This was originally added by Kww for what I guess was tracking abuse, but indeed Sam is right that when VisualEditor came around we eventually had the filter add tags to track the wealth of extraneous nowiki tags being added. I don't think this is as much of an issue anymore, and we also have Special:AbuseFilter/631 (not to be confused with 345) that tracks general extraneous markup being added. I propose we merge 550 into 631 as it seems they serve more or less the same purpose, as it stands now. Pinging Salix alba who re-enabled the filter in 8 June 2014 MusikAnimal talk 05:20, 29 December 2015 (UTC)

The insertion of extraneous nowiki tags is still one of the biggest issues in visual editor, its one of the blocking issues about the wider rollout of the editor. Generally every time VE adds one its in error. If you look at the recent change log [11] it shows more than 50 mistakes a day. You get errors like Kebumen_City which don't have a visible effect but generate bad wikicode. As it addressed a specific set of bug it useful to separate out this from other extraneous markup filters. --Salix alba (talk): 06:15, 29 December 2015 (UTC)

As this is dealing with a Visual Editor bug could someone change filter 550 so it only looks at V/E edits and ignores edits done via the classic editor? That should prevent incidents like the one that started this thread. ϢereSpielChequers 20:28, 30 December 2015 (UTC)

While this is a good idea, I don't think we can filter by editor type (VE/not). Sam Walton (talk) 20:37, 30 December 2015 (UTC)

Appreciation

Just a note to say I am absolutely certain that the vast majority of editors are completely unaware of how much their editing lives are improved by the quiet work done here. Unfortunately it's a little like being an intelligence agent, in that public accolades risk impairing the effectiveness of the very efforts being praised. I, at least, appreciate it. EEng (talk) 09:24, 30 December 2015 (UTC)

I'm another (normally) silent watcher. The abuse edit filter and those who drive it perform wonders. Johnuniq (talk) 09:37, 30 December 2015 (UTC)
Oh, you like to watch abuse too? Can I... email you? EEng (talk) 04:25, 31 December 2015 (UTC)
Me too. My watchlist sees far less vandalism because of the edit filters, the only down side of the edit filters are that certain pessimists who judge the health of the community by raw edit count get to interpret good news as bad. ϢereSpielChequers 20:21, 30 December 2015 (UTC)

"pre-save transformed" variables

Does anyone know how the "pre-save transformed" variables such as added_lines_pst, removed_lines_pst, and edit_diff_pst differ from their normal counterparts? Prodego talk 20:50, 2 January 2016 (UTC)

meta:Help:Automatic_conversion_of_wikitext has a little info on it, still checking. — xaosflux Talk 21:27, 2 January 2016 (UTC)
The preSaveTransform does substitution of {{subst:}} templates, signatures ~~~~, the pipe trick, and cleanup of newlines. I believe the pst versions are suppose to run tests on the wikitext before these processes occur. However, because the pre-save text is never saved in the database, this content is not available for batch testing or diff examinations. As a result I generally avoid using the pst variables. Dragons flight (talk) 21:28, 2 January 2016 (UTC)
The ~~~~ shows in this hit, so obviously it does show. (I found itsimply by looking at a filter which hits only talk-page edits, filter 478 (talk page abuse). עוד מישהו Od Mishehu 09:28, 3 January 2016 (UTC)
What gets saved in a disallowed edit is subtly different than what gets saved when an edit completes successfully. You can't find untransformed ~~~~ when batch testing or looking at diffs of completed edits. Dragons flight (talk) 09:48, 3 January 2016 (UTC)
It may be difficult to test them, but the filter is technically capable of checking for them; the best way to test would be to have an alternate account used precisely for this purpose. עוד מישהו Od Mishehu 16:03, 4 January 2016 (UTC)

Two edit filter RfCs

Please vote and join discussions at two RfCs regarding the edit filter, including the possibility of enabling its blocking ability. Sam Walton (talk) 18:20, 9 January 2016 (UTC)

What should the criteria for use of the block function be?

There's been a recent Idea Lab discussion about enabling the Edit filter's block function, and I'm aiming to make a couple of proposals as a result, but I'm not completely certain what to propose for one point, namely what the Guideline should say about blocking. Each method I think of has some shortfalls, but something like this would be my proposal: "The blocking function must not be enabled for a filter which has received any false positives in the past 30 days, and should only be used on filters where editors tripping the filter are always currently blocked manually. At least 3 administrators must agree that these requirements have been met, in a public venue such as the edit filter noticeboard prior to the enabling of this option."

While this isn't the proper RfC (so don't vote on this in particular!), do you think this is a sensible proposal or should it be more or less strict? Sam Walton (talk) 14:42, 1 January 2016 (UTC)

Less strict - but I'd want to see something about requiring admins to regularly monitor any filter blocks - perhaps a bot generated table of any such blocks that can be watched? — xaosflux Talk 16:10, 1 January 2016 (UTC)
Those are logged to the normal block log. See m:Special:Log/block/Abuse_filter for example. --Glaisher (talk) 16:32, 1 January 2016 (UTC)
Though here they'd be placed by User:Edit filter because of MediaWiki:Abusefilter-blocker. Sam Walton (talk) 16:48, 1 January 2016 (UTC)
Some thoughts:
  • Any automated block should, at least for now, be no more than the time it takes to get an administrator to manually intervene and either extend the block or disable the "blocking" functionality of the filter if it made a false positive.
  • It should also (ideally) only be used when the editor is making bad edits so fast that waiting for human intervention would do more harm than good.
  • I hope that means the auto-block will be less than 1 hour but with time zones being what they are the reality is it may mean the "filter-imposed block" is more like 3-6 hours, and only "block" the editor if there have been at least two such "bad" edits during the last X time period, where X is the length of the block.
  • The editor should POLITELY be told that the block was automated and that an administrator will look at the edit shortly and either un-block the editor or extend the block, depending on the circumstances.
  • To ensure prompt admin attention and to calm the editor down, add a template to the editor's user page that combines the "you are blocked due to this edit" message with a pre-canned "unblock-request" message. The assumption is that the pre-canned unblock-request message will put the user's talk page in a category that will get fast administrator attention and that it will stay in that category until the block expires ({{Alarm clock}} and {{Age switch}} are good tools to manage time-based categorization, provided the user's talk page is purged at regular intervals).
  • The fact that someone was blocked by the filter itself should explicitly be considered as having no bearing on future actions, such as being blocked, running for administrator, etc. Of course, any human extension of that block (which would be the typical case outside of false positives) would be prejudicial, as would the underlying edits themselves ("ooh, you spammed and got bot-blocked and no administrator extended the block, that's still a black mark for you" or "oh, sorry you triggered the blocking edit filter, it's unfortunate that no administrator unblocked you with the comment of 'edit filter false positive' but we see that now and won't hold it against you at RfA").
davidwr/(talk)/(contribs) 17:52, 1 January 2016 (UTC)
  • While I sympathise with the idea, I'd only advocate using the block function where we can be all but certain that the filter is only catching the intended, always blocked, recipient. Examples include 666, 673, and 674 where there have been months of logged edits which are not false positives, and the editor is always blocked. As such I don't see a need to go out of our way to be quite so careful and polite. Sam Walton (talk) 18:32, 1 January 2016 (UTC)
  • Edit filter 666 is private. I'm pretty sure I don't want to know why. 0:^) davidwr/(talk)/(contribs) 23:06, 1 January 2016 (UTC)
  • Agreed with Sam. The block should not be used for any situation where there is any doubt it's the target bad-faith editor. For long-term abuse giving no recognition is going to be favourable. Does the extension allow automating of talk page notices? MusikAnimal talk 06:27, 2 January 2016 (UTC)
  • Not as far as I'm aware, though I assume setting up a bot to do this wouldn't be hard. Sam Walton (talk) 14:13, 2 January 2016 (UTC)
  • In most cases, no false positives in a month's time sounds reasonable. We have to remember we've been getting by just fine without blocking functionality, so I don't see the harm making us wait a little bit so that we can know for certain the filter is doing it's job correctly. However if the filter is getting tripped at a high rate, it might offer just as much evidence. Maybe the requirement should be something like 30 days or 100 consecutive accurate hits. It's hard to come up with a strict guideline, as it really varies case by case. I think we should probably always start with disallow, and not jump right to blocking. Notice that a filter is being considered for blocking should be obligatory, along with admin review of the blocks. I can see some cases for private filters where you might want to do this through the mailing list, though. Also, are we able to specify block options the filter would impose? MusikAnimal talk 06:27, 2 January 2016 (UTC)
    • @MusikAnimal: 100 consecutive edits seems a sensible addition. I agree about setting to disallow first, but it seems like that would almost always be the case anyway; the criteria here for blocking are much higher than those typically used to justify turning on a filter's disallow setting, not sure we need to specify this in the guideline. We can specify the length of blocks for registered and IP editors separately; I think I'd propose indefinite and 31 hours respectively since - as I mentioned above - we should really only use this on cases where we would be blocking accounts indefinitely anyway. We can also specify the block log message (MediaWiki:Abusefilter-blockreason) and what the user sees upon being blocked (MediaWiki:Abusefilter-blocked-display). Sam Walton (talk) 14:13, 2 January 2016 (UTC)
To me, a blocking filter (which I strongly support) is a non starter unless whichever admin last changed it (and optionally more) are notified of and responsible for every block the filter makes. By notified I do not mean just a page that lists any blocks (also a good idea) but an actual alert of some kind, such as the new message notification. I don't think any other criteria are needed. Prodego talk 06:33, 2 January 2016 (UTC)
There is no native capacity in the AbuseFilter for issuing notifications or posting on talk pages. However, since everything gets logged, one could imagine writing a bot that frequently checked the log and promptly posted whatever notifications the community had agreed upon. Dragons flight (talk) 15:44, 2 January 2016 (UTC)
Maybe a page, with a list of multiple {{ping}} recipients; we can't assume any one admin will be online at any time. — xaosflux Talk 16:17, 2 January 2016 (UTC)
Sounds good to me, and am happy to take on the bot work involved. Figuring out who to ping might be tricky, though. I should be able to figure out who added the block function, so we can ping them, and maybe other admins who contributed to that filter. The pings should be an "opt-out" service, so the bot doesn't indefinitely ping admins who may or may not still be interested in that filter. So I guess we'd have one page with headings for each of the blocking filters, and the bot would ping relevant admins when a block occurs, also stating who was blocked. A separate /opt-out subpage would have the same list of filters, but admins can add their username below the heading for whatever filter they don't want to pinged about. How does that sound? MusikAnimal talk 21:49, 2 January 2016 (UTC)
I think we need to test this out outside of enwiki first, perhaps a request to enable this ability on testwiki first? — xaosflux Talk 21:58, 2 January 2016 (UTC)
You could also ask for insights at Meta or one of the dozen other wikis that already allow use of the block function. Dragons flight (talk) 22:08, 2 January 2016 (UTC)
One thing that I like on meta: is that the blocks can be set to give a "final warning" before blocking, I'm thinking we should seriously consider that as well. Example warning is meta:MediaWiki:Abusefilter-warning-spam-willblock. — xaosflux Talk 17:10, 3 January 2016 (UTC)
Can this be configured on a per-filter basis? For long-term abuse we will likely want to go straight to blocking, and not issue any templates. This system of block and WP:DENY I think will work wonders, being a major deterrent for persistent socks MusikAnimal talk 18:31, 3 January 2016 (UTC)
Unless I'm wrong, I assume this is simply done by having the filter set to Warn (with that message) and Block. Sam Walton (talk) 19:18, 3 January 2016 (UTC)
Yes, the filter can BLOCK without warning first. On a warning they will see the warning message, and if they try to hit save again then they get blocked. — xaosflux Talk 20:09, 3 January 2016 (UTC)
  •  Comment: Samwalton9 asked for my comment as I have had some experience in its use. Blocks are for indefinite periods, so as such are harsh and IMO should only ever be used where the AbuseLog is being actively watched and reviewed; if it is not, then it should not be used. Accordingly I also think that it should only ever be used for account names, not for IP addresses, as I am not in favour of indefinite IP blocks. So to me they are an option of last resort, need to have passed quality testing, and on filters that have step-wise made their way to this last step, and there are no false positives in recent history. Where there is a false positive, it requires immediate amendment, or a step-down. — billinghurst sDrewth 02:25, 10 January 2016 (UTC)
@Billinghurst: The proposed configuration changes include a block length of 31 hours for IP addresses. -- John of Reading (talk) 07:56, 10 January 2016 (UTC)

Looking to help

I'm a long term editor who also happens to be a computer programmer (25 years of flipping bits, mostly embedded stuff but with a bit of web things here and there - resume here). I often poke around on informal anti-vandal patrol now and then and have been looking for a way to contribute more to Wikipedia, preferably something that leverages my technical skills. I don't have a huge amount of time to spare, just a few hours a week, so applying to be an Administrator seemed a bit of overkill. User:KrakatoaKatie suggested I look helping out with Edit Filters.

Is this something I could help out with? If so, how would we proceed? I'll watch this page for a response.

Thanks KNHaw (talk) 23:40, 24 January 2016 (UTC)

@KNHaw: Absolutely! I'd recommend you first take a look through some non-hidden edit filters at Special:AbuseFilter, look at the log of caught edits for those filters, and generally get a feel for how the filters are written and how they work. mw:Extension:AbuseFilter/Rules_format is a helpful reference page for how they're written, and of course feel free to ask me or any other active edit filter managers if you're not sure on something. If you're not familiar with regular expressions I'd also read up on them and have a play around with them in something like Debuggex. Once you feel like you're happy with how edit filters work we could primarily use some help responding to false positive reports, of which we get a lot. Then there's also the requests page, where you're welcome to help with creating new filters (if the request is related to a vandal you can submit a proposed filter to the mailing list and we'll create it hidden). If you want to get more involved than this (i.e. actually creating and editing filters), you can apply for the edit filter manager user right, for which you do not need to be an administrator; we'd just like to see that you know what you're doing first! Hope that helps and do feel free to drop me a message if you have any questions about the edit filter. Sam Walton (talk) 23:57, 24 January 2016 (UTC)

Citebomb?

What is with the pseudo-citations in the article linking to pseudo-random ArbCom decisions and what not? I count about 23 of them. Even if someone reverts a statement with basis in consensus, it is easy to revert, providing a link to the discussion. Esquivalience t 03:00, 1 February 2016 (UTC)

Hi Esquivalience. The style of the quasi-citations is taken from the Admin policy. It's unusual I agree. They're, ahem ;), not really pseudo-random. It made some sense to place them there--at least initially--so the origin, basis in consensus, in policy and/or ArbCom decree'd be easy to find early on. I'm happy to take a look todayish to see if I can reduce them. –87.115.76.251 (talk) 07:36, 2 February 2016 (UTC)
I'm not happy about linking to ArbCom "Principles". Though these are sometimes reused by ArbCom, they have (or should have) no force outside the internal logic of ArbCom decision making - even there, they need to be voted on every time they are used. ArbCom is explicitly not a policy making body, though they have on many occasions attempted to be one by various methods, with more or less success. All the best: Rich Farmbrough, 10:46, 2 February 2016 (UTC).

Removing EFM rights for those desysoped under a cloud

Should the following be added to the user right section of the policy;

Any administrator who has the edit filter manager right and is desysoped under a cloud should also have their edit filter manager right removed, regardless if they held it prior to becoming an administrator. They may regain it through the normal process at edit filter noticeboard.

Support

  1. Support as proposer. Regardless of the current practices, I feel this should be in writing, as we all know the power (and room for abuse) that exists with edit filters. If an admin is no longer trusted by ARBCOM or feels the need to resign under a cloud, it seems reasonable that no longer hold the trust of the community to be an edit filter manager. Kharkiv07 (T) 20:33, 18 January 2016 (UTC)
  2. Support, sort of. I don't agree with "regardless if they held it prior to becoming an administrator" - if they gained it prior to becoming an admin then they evidently have the trust of those who understand the edit filter from a primarily technical standpoint. I support removal of the user right if it was self-granted though; this implies that it was trusted to them through the same means as the rest of the admin toolkit, for which they no longer have the community's trust. Sam Walton (talk) 23:31, 19 January 2016 (UTC)
  3. Support (or neutral I guess) – I agree with others that it really varies case by case. If the admin has been desysoped for behavioural reasons, I would hope the abusefilter right is removed... without question. I also agree with Sam that self-granted rights should be removed, as they added it only because they had the admin bit, which they've now lost.
    Another thought is to first see if they've even modified any filters. If they haven't, it might be because either they thought they needed it to view filters, or they just added it when they were an admin because they could – such people probably account for most of our edit filter managers. Very few are actually doing anything with it. I wrote a tool to report which EFMs haven't made any filter modifications, but alas that effort was cut short by a security flaw which WMF is now working on. We should be able to report this information again soon, though, and I think we should look to it moving forward, perhaps even for our current admins MusikAnimal talk 16:54, 20 January 2016 (UTC)
  4. Support. The idea is sound, the wording is atrocious. The closing person will need a great wisdom to extract what is supported in both the support and oppose sections. The main fact is that there are circa 1300 administrators and only 166 Edit Filter Managers. There are so few EFM because an EFM must be trusted for: (1) technical skills; (2) good judgement. The actual rules are (R1) any admin can grant the right to any admin (even herself) ; (R2) a non-admin must go before the EFM noticeboard. Rule R1 is absurd and R1+R2 should be changed into: "any admin+EFM can grant the right to any admin (checking skills); EFM noticeboard can grant the right to any non-admin (checking skills+good judgment)". And now the desysop rule is obvious: "when an admin+EFM is desysopped then (1) if the EFM status was granted by an EFM (either the noticeboard or a single other EFM+admin), the EFM status remains, except if explicitly revoked by the Arbitration (2) if the EFM status was granted by a non EFM admin (old deprecated rule), the EFM status is revoked (but can be obtained again, without delay, following the rules for a non-admin)". Pldx1 (talk) 12:07, 21 January 2016 (UTC)

Oppose

  1. Oppose per the Rich Farmbrough precedent; they were demopped in 2012 and kept the EFM access (to be precise, it was removed during the desysop, but another admin immediately restored it, inducing a discussion on the administrator noticeboard here) - and from what I know they do good work there. I don't think a desysop necessarily implies that one is unsuitable for holding edit filter manager access, especially since IMO technical proficiency is a more important component to EFM than to adminship while complaints about bad judgment seems to be far less common there. I also think we need a much better case before creating yet more policies.Jo-Jo Eumerus (talk, contributions) 20:46, 18 January 2016 (UTC)
  2. Oppose If an editor has the EFM right granted as a separate request per the normal process at EFM this would have been based on their ability and knowledge of the area not their ability to use administrator tools. If they weren't granted per the normal process then that's a different matter but blanket removal of permissions shouldn't be carried out unless they were given in the same manner. We'd need to potentially remove things such as file mover or rollback that are both for "trusted users in that area". Amortias (T)(C) 21:01, 18 January 2016 (UTC)
  3. Oppose. I would support an automatic removal of EFM only if arbcom directs this or they have only held the right through self-granting it (if they gained it through a discussion, returned it for reasons other than misuse, and then later self-granted it again then it should not be considered a self-granted right for this purpose). In all other cases I would say a review of whether they are still suitable is recommended. Thryduulf (talk) 22:31, 18 January 2016 (UTC)
  4. Oppose per Thryduulf. -- KTC (talk) 23:37, 18 January 2016 (UTC)
  5. Oppose Existing policy allows us to give and take away this right. We can go on a case by case basis. HighInBC 15:53, 19 January 2016 (UTC)
  6. Oppose - EFM != sysop. EFM only covers technical ability and/or basic common sense. Sysop requires a lot more. Reaper Eternal (talk) 23:19, 19 January 2016 (UTC)
  7. Oppose as written. Removing self-granted EFM is reasonable, but if they were given EFM through some other process, it should not automatically be removed. --Carnildo (talk) 01:10, 20 January 2016 (UTC)
  8. Oppose in principle. I agree with Thryduulf, that self-granted EFM rights should be removed. Editors who were granted the right prior to adminship hold EFM as a separate right, and should retain it (unless obviously the case found they had abused EFM). This may have to be put into the ArbCom procedure, to check to see if the user has self-granted the right, and include its removal in future remedies (as appropriate per above). So while I would support removal for self-granted rights, I oppose this as a blanket "thou shalt have EFM removed upon desysoping". --kelapstick(bainuu) 20:35, 20 January 2016 (UTC)
    • If there is significant abuse or misuse of the edit filters then it is very likely that arbcom will resolve the right should be removed, as happened with Kww. In other cases, the clerks will now leave a note at WP:EFN if a user with self-granted EFM rights is desysopped. I'm not sure more is needed from arbcom than that as the right can be added or removed by administrators. Thryduulf (talk) 21:50, 20 January 2016 (UTC)
  9. Oppose It is up to ArbCom to be precise in the language they use. There are many bits which could be removed along with the admin bit: if more than the admin bit is meant then it should be so specified. All the best: Rich Farmbrough, 23:33, 29 January 2016 (UTC).
  10. Oppose per Rich Farmbrough's points immediately above: removal of rights other than adminship should depend on the individual case. Rubbish computer (HALP!: I dropped the bass?) 14:08, 3 February 2016 (UTC)

Comments

  • I think it depends if it was self-administered or not. In general, EFM is considered a restricted right, but it can be given to non-admins after discussion at Wikipedia:Edit filter noticeboard. Admins can self-apply the right at will, in which case we are relying on the trust they have as admins. Therefore, if the admin is desysopped for cause, that trust is no longer extant and the EFM right dissipates along with it. However, if they had the right prior to their being an admin, then their ability to maintain it is dependent on a different trust, and may extend beyond the desysopping, although, I would recommend that the EF noticeboard make some mention of that fact. -- Avi (talk) 21:44, 18 January 2016 (UTC)
    • Not so. De-sysopping "for cause" does not necessarily stem from lack of trust. I might mention a case where "lack of responsiveness" was cited. All the best: Rich Farmbrough, 10:41, 2 February 2016 (UTC).
  • I think this situation should require a review to determine if this flag is still needed, but not necessarily require the removal. The key factors should include the same as for non-admin appointees:
    1. Does the editor maintain a standard of "good judgement"?
    2. Does the editor have demonstrable "technical proficiency"?
    3. Is the editor "highly trusted"?
    4. Was the editor actually active in this area?
    xaosflux Talk 21:47, 18 January 2016 (UTC)
    I like this idea, and I'll put in a recommendation to arbcom that the clerks put a note on the EF noticeboard if arbcom desysops someone who has the EFM right. Thryduulf (talk) 22:33, 18 January 2016 (UTC)
    And the recommendation was accepted for users with self-granted EFM rights. Thryduulf (talk) 21:51, 20 January 2016 (UTC)
  • Support the idea of a "review" of continued EF rights holding on a desysop "case by case" basis. --IJBall (contribstalk) 17:23, 19 January 2016 (UTC)

Recent changes to guideline

87.115.76.251 (talk · contribs · WHOIS) has recently added a significant amount of content. A lot of it I wholeheartedly agree with, but some of it is disputable, and we shouldn't being drawing conclusions directly into a guideline without clear consensus. I also think we might be going a little overboard in general by bloating the same information that we already had beforehand. No need to be that thorough, we should be concise. I've reverted the content for now, and have informed 87.115.76.251 of this so we can discuss further. Thanks MusikAnimal talk 21:17, 3 February 2016 (UTC)

Documentation

I have completed the documentation at Wikipedia:Edit filter/Documentation; feedback or fixes are appreciated. Esquivalience t 03:05, 14 February 2016 (UTC)

Which abuse filter would be good to assess the following?

Hello. I am an editor creating articles here. I have just expanded my scope to reviewing vandalism and other issues. I wanted advise on which filter will be good to review the following:

  1. . Coi cases of user name being the same as or similar to article name
  2. . Abusive usernames
  3. . Vandalism (that might not be reverted by Cluebot)
  4. . BLP vandalism

There are so many filters I see so I am confused.

Thank you. Xender Lourdes (talk) 04:26, 10 March 2016 (UTC)

@Xender Lourdes:
  1. Special:AbuseFilter/148
  2. Abusive usernames aren't really tracked by the edit filter as this task is done by a bot which reports to Usernames for administrator attention directly. You can patrol WP:UAA/BOT to help out by removing obvious false positives or warning users with borderline cases.
  3. The "possible vandalism" tag is the best to patrol for this - [12]
  4. As above but the "possible libel or vandalism" tag - [13].

Hope that helps! Sam Walton (talk) 20:29, 13 March 2016 (UTC)

Thank you Samwalton. Xender Lourdes (talk) 00:14, 23 March 2016 (UTC)

Is WP:CENSOR now a historical policy?

I was trying to change a quote in the Donald Regan article "expletive you" to "fuck you". In the past usually a flag was triggered when a valid edit was made. Now that is no longer the case. Preventing curse words to be in articles, when it is appropriate as in not having to censor a quote, seems to indicate a change in what Wikipedia espoused as a policy regarding censorship. 166.172.60.147 (talk) 18:54, 13 May 2016 (UTC)

No, you're quite right; I've gone ahead and made the change. Sorry that the filter caught you on a false positive, but I'm sure you can understand that usually IPs that add words like "fuck" to articles are doing it to vandalize. I'm not quite sure what we could do to reduce this false positive; I think it might just be one of those things. The edit filter isn't a reflection on the NOTCENSORED policy, just an indication of the reality of most IP edits inserting profanity into an article. Again, sorry about that. Writ Keeper  19:44, 13 May 2016 (UTC)
I think we did what we can do. The false positive was reported and someone made the edit. These things are going to happen in these edge cases. See the Scunthorpe problem. HighInBC 19:47, 13 May 2016 (UTC)

Revocation of autoconfirmed rights

Out of pure curiosity, I heard that the edit filter is capable of revoking one's autoconfirmed rights. This sounds like a very harsh action for a mere edit filter to take, so I was wondering:

1) Has this ever been used in any edit filters?

2) If not, in which circumstances is it designed to be used?

3) Does this temporarily disable your autoconfirmed rights, or does it strip your account of them and require you to ask at Requests for Permissions to get them back?

Thanks, Passengerpigeon (talk) 22:07, 12 May 2016 (UTC)

I'm speaking without the book here, but I don't believe anything like that is used in any current filters at enwiki. The edit filter actuslly has a fairly broad technical capability, including the ability to outright block people. But just because it's possible to do so doesn't mean it's allowed.
As far as autoconfirmed goes, I think that, once it's removed, the software detects the removal and won't regrant it. But again, I'm not totally sure of that. Writ Keeper  22:26, 12 May 2016 (UTC)
These features are not enabled on enwiki. As for the removal, there is a sysop tool to restore it, also not enabled. — xaosflux Talk 01:29, 13 May 2016 (UTC)
From the Finnish Wikipedia I can say that the status of 'autoconfirmed user' is only temporarily disabled and it is automatically restored after four days. When the filter takes away the rights, it "resets the counter" in a fashion. When four days have passed the user will be autoconfirmed again – as if he were a completely new user who would have to fill the required criteria (normally 4 days, and on en-wiki 10 edits). The option is enabled on the Finnish Wikipedia, but we have never used it, except for testing purposes. --Pxos (talk) 11:47, 7 July 2016 (UTC)
It does exist in at least one deleted filter: 21. All the best: Rich Farmbrough, 20:50, 18 August 2016 (UTC).

Please rid of this filter.

It's getting on my nerves, always blocking out edits whenever least desired. It's the prime source of frustration for us editors. Snacker10 (talk) 03:48, 9 September 2016 (UTC)

Okay, maybe not downright rid of the filter,

But if it is triggered, it should at least specify what did. Snacker10 (talk) 03:59, 9 September 2016 (UTC)

It does. I thought it would have been pretty obvious you were blocked for cursing. You have to be around for a bit longer before the filter starts letting you curse on talk pages. Someguy1221 (talk) 04:45, 9 September 2016 (UTC)

Private deleted filters

What's the point of that anyway? If the filter is deleted, it means it's not going to be used anymore - so why can't any sensitive conditions/notes be blanked and the filter made public? Why are there private filters anyways, except for testing purposes? 50.199.236.1 (talk) 13:04, 5 December 2016 (UTC)

Hi IP, we often make our filters private to help prevent the target of the filter from adapting and evading the conditions. When a filter is deleted, the previous versions of it are still available, so making these public isn't the best idea for similar reasons -- samtar talk or stalk 13:07, 5 December 2016 (UTC)
Well, someone who is evading blocks or other sanctions would be blocked anyway, and when you're blocked you can't view the abuse filters regardless. 50.199.236.1 (talk) 13:38, 5 December 2016 (UTC)
Untrue. Anyone can view the public abuse filters, even logged out editors. Someguy1221 (talk) 20:44, 5 December 2016 (UTC)
Aren't edit filters just supposed to stop repeated or commonly harmful edits or actions? Why would their be a filter targeting one editor - isn't that what blocking/banning is for? 50.199.236.1 (talk) 12:28, 7 December 2016 (UTC)

Advice for Turkish Wikipedia

I've had a request from the Turkish Wikipedia for some advice, they have an image vandal adding images of shit etc and are wondering if an edit filter stopping newbies adding images in their first 100 edits is the best way to handle this. I don't think they have enable the image filter yet. ϢereSpielChequers 16:49, 13 December 2016 (UTC)

Where are these images being added primarily? A filter preventing new users (measured by unconfirmed/account age/edit count) adding images to the articlespace could be used to counter this. Then there's more interesting possibilities if they are primarily IP addresses from certain ranges etc etc -- samtar talk or stalk 16:56, 13 December 2016 (UTC)
They have tr:MediaWiki:Bad image list. Add liberally. IMO, it's about the best way to deal with this type of problem unless the images or pages have a common name (edit filter), or range blocks can be applied. Of course here, new users are always adding images legitimately so an edit filter which prevented newbies from adding images anywhere would not be appropriate. -- zzuuzz (talk) 17:04, 13 December 2016 (UTC)

Guideline updates for deferred changes

As part of the deployment of deferred changes, we'll need to update this guideline. I suggest to add the following to the Basics of usage section between warn and tag levels:

  • The next lowest setting is to defer actively. In this case, the edit will be added to Special:PendingChanges for review and will not go live until reviewed.
  • The next lowest setting is to defer passively. In this case, the edit will be added to Special:PendingChanges for review but will sill go live immediately.

And to add a paragraph at the end of the Recommended uses section:

For edit filters targeting reviewable namespaces (currently only mainspace and project space), edit filters can be set to defer for review passively or actively. Per the RFC on the subject, edit filters should be set to defer passively before being set to defer actively. During the passive phase, the backlog should be watched carefully[1] and matches should be scrutinized for false positives. If the backlog grows excessively, it means deferring is not appropriate for the filter, or it should be modified to diminish catch rate. If there is a substantial number of false positives, then the filter should not be set to defer actively, or it should be modified to diminish false positives. If both the backlog and false positives are kept in check, then the filter may be set to defer actively.

  1. ^ This page can help in this regard.

Cenarium (talk) 00:53, 23 December 2016 (UTC)

Edit filter rule "Disallow adding {{persondata}}"

Roll-back is a standard method of dealing with copyright violations. Until today I've been able to do that using the [restore this version] option provided by Twinkle. Now, when trying to roll back a biography to the last clean version, I'm blocked by this edit filter, which gives the message:

The following warning was returned by the edit filter:

Edit disallowed: {{persondata}} has been deprecated, it should not be used anywhere. Machine-readable information should be added to Wikidata instead.

If you wish to proceed with the rollback, please reload this page (F5 or Ctrl+R) and carry it out again. This warning wil [sic] not appear a second time

But if I reload the page and try to make the edit as instructed, I just get this:

The edit was disallowed by the edit filter rule "Disallow adding {{persondata}}".

Any advice on how to actually do the roll-back? I know of course that I can do it manually – find the revision number and editor of the last clean version for the edit summary, edit that version, remove the damned persondata, and save. But copyright clean-up is already time-consuming, we really don't need anything that makes it more so. Can I, for example, request exemption from the filter (I'm a copyright clerk)? Justlettersandnumbers (talk) 13:50, 28 December 2016 (UTC)

@Justlettersandnumbers: This filter should not have been disallowing edits without an appropriate consensus (I've notified the creator), so I've turned that option off. You should be able to make these edits with just a warning now. Sam Walton (talk) 14:08, 28 December 2016 (UTC)
Thank you, Samwalton9, that's a relief! Now, what about an edit-filter that would catch copyvios before they are saved … ? Justlettersandnumbers (talk) 14:16, 28 December 2016 (UTC)
Wouldn't that be nice! Unfortunately we're beholden to the bots for now. Sam Walton (talk) 14:19, 28 December 2016 (UTC)
There is a filter that catches articles created as big blocks of text added without wikifying and another which catches things that look like copy-and-paste moves or recreation, which is oftentimes a sign of copyright violation. Jo-Jo Eumerus (talk, contributions) 14:26, 28 December 2016 (UTC)
I know, I know! But it's not impossible to imagine a routine that would ask new and IP editors to wait a few moments for their edits (over a small minimum size) to be saved, and in that time do a CorenSearchBot-type check of the proposed content … some day, perhaps. Justlettersandnumbers (talk) 15:40, 28 December 2016 (UTC)

"Contact 09035865525"

An IP-hopping spammer has been adding "Contact 09035865525" to many Nigerian university articles, e.g. [14], [15]. User:Materialscientist tells me "This is an LTA case, and some socks are here. All edits come from the 197.210.0.0/16 range, which is busy, but we might consider blocking it. The added phone numbers vary." Looking at the sock contributions, they do indeed vary. I can think of a few string + number regexes to filter on, but don't know anything about how the edit filter works on WP. Any thoughts on how best to filter these? Thanks, Wikishovel (talk) 06:26, 29 December 2016 (UTC)

Wikishovel hop over to Wikipedia:Edit filter/Requested (which has a lot more viewers) and just describe the pattern. — xaosflux Talk 16:26, 29 December 2016 (UTC)

Confusing edit filter result

Hey guys, I'm trying to figure out why Special:AbuseFilter/examine/log/17828520 is not a positive match to Special:AbuseFilter/839. This edit was hit by 839 earlier today, but now when I run the examine utility, or the batch test, it doesn't generate a hit. I can't seem to make it hit no matter how I edit the filter in the examine function. Someguy1221 (talk) 23:09, 17 February 2017 (UTC)

@Someguy1221: Strange that loading the filter to test doesn't work, but loading up the batch testing tool and running it against user 82.38.78.143 does flag the edit correctly. Sam Walton (talk) 23:13, 17 February 2017 (UTC)
I gave up on the 'examine' tool some time ago. I figured it was broken as it didn't contain all the fields being tested, as it did before I gave up on it. I've no problem with batch testing, where I also see a hit. -- zzuuzz (talk) 23:31, 17 February 2017 (UTC)
I think the examine tool also updates after the edit has been made, which isn't very useful... Sam Walton (talk) 23:35, 17 February 2017 (UTC)
Some variables are lost after the filter hits. E.g. here when examining the edit you'll notice "edit_delta" is not listed as a "variable generated for this change", so any code that uses "edit_delta" won't work when examining this particular change. I'm not sure why the software was set up like this, perhaps at run-time any unused variables are not stored for performance reasons. There's a phab at phab:T143353 MusikAnimal talk 16:27, 19 February 2017 (UTC)

RfC: use of edit filter against unreliable sources

This RfC essentially asks if Wikipedia should double-down on its just-enacted ban on the Daily Mail by introducing a technical impediment that would prevent - or warn or blacklist or electro-shock - Wikipedians trying to link to it (and similar sites). While there's not a consensus as to the form such a filter should take (A number of editors seems to support creating surveillance logs of people who try to link to the Daily Mail "so that we can monitor the use of the Mail as a source"), there is a consensus to introduce a filter. And that consensus is supported by a 2-1 margin. Further, as Guy Macon notes, there has already been a decision (which this couldn't overturn) that an edit filter should be introduced for the DM on top of its notional ban. BlueSalix (talk) 03:29, 18 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should edit filters be used to prevent citing sources deemed unreliable, or warn editors trying to do so, or log such actions? TigraanClick here to contact me 13:45, 9 February 2017 (UTC)

Statement amended, seeing the discussion below. The spirit of the amendment was already in the extended content, in particular the second paragraph. TigraanClick here to contact me 19:13, 9 February 2017 (UTC)
See important note below: Wikipedia_talk:Edit_filter#Proposer.27s_remorse_suddenly_strikes TigraanClick here to contact me 19:30, 9 February 2017 (UTC)

Extended content

The question is whether when a source is deemed unreliable by community consensus, an edit filter can be set to ward off attempts to cite it. The intended use is mostly against online sources because URL regular expression matching is easy, but it could be used to other sources as well if technically feasible.

By default, a "support" vote means that any filter setting can be used (subject to Wikipedia:Edit_filter#Recommended_uses); consensus for the use of a filter could decide to set a "log", "tag", "warn" or "disallow" level. If you think only specific filtering levels should be allowed or encouraged, please specify it.

A few clarifications:

  • This proposal does not precisely define sources deemed unreliable on purpose. The default I envision would be that community consensus can establish an edit filter on a case-by-case basis, but sources previously deemed unreliable would not be eligible; consensus would have to be established specifically for the use of an edit filter. Another RfC could establish criteria to consider for an edit filter to be set (e.g., widespread use by new editors, extra-unreliability threshold, etc.).
  • Community consensus can already impose pretty much anything, including edit filters. The question is whether it should be done, on a somewhat regular basis. In particular, the objective is to address potential technical limitations, or policy objections to the use of edit filters for that purpose. Edit filters are currently used for vandalism or close-to-vandalism disruptive editing from IP hoppers; the proposed use is a change of philosophy.
  • This proposal does not establish the organization of such filters. I would personally support the creation of an "unreliable sources list" (1) for easier audit of what sources were banned, when and for which reason, (2) to point out to users unfamiliar with it, (3) to allow an easier justication of a bypass of the ban (e.g. citing source Foo on the article about Foo would have legitimate uses); but such a proposal should be discussed separately.
  • Should this proposal pass, it should not be construed as an encouragement to filter as many unreliable sources as possible; neither should the absence of an edit filter against a source constitute an indication that the source is deemed reliable.

Context

This RfC on RS/N was closed recently, establishing the use of an edit filter set on "warn" against citing the Daily Mail. I commented here. Much of the discussion focussed on whether the DM is a reliable source and whether a blanket ban on an unreliable source is acceptable or needed; however, the technical implementation was almost not discussed, even though it was an important part of the proposal in my view.

Since that RfC may constitute a de facto precedent for a blanket ban on multiple other "mainpress" but unreliable sources, concerns about the technical implementation should be addressed separately. Ideally, this would have been done beforehand, but better late than never.

Survey

  • Support as proposer. Unless technical issues arise, there is already a de facto ban on some sources (e.g. the DM) on Wikipedia: inclusion of such sources would be reverted on sight by most editors (or at least they would demand a better source for the supported material). It makes sense to use edit filters as a technical solution to at least warn against inclusion. TigraanClick here to contact me 13:45, 9 February 2017 (UTC)
  • Comment- I question whether this would work. Reliability often depends on context. A given source may be completely unreliable for a statement of fact (X is Y), but perfectly reliable for a statement of opinion (Z believes that X is Y). An automated system will not be able to determine how the source is being used... whether the source is supporting a statement of fact or a statement of opinion. Blueboar (talk) 14:06, 9 February 2017 (UTC)
    • Sorry for the badgering, but well, you were the first. See "context": there is already a case of consensus for such an edit filter, so it's not a solution in search of a problem. Whether such a ban is appropriate/efficient or not is a matter for another discussion (see "clarification #1") - the question here is, if it is deemed appropriate to forbid a source (by other ways not discussed here), is an edit filter an appropriate technical implementation? TigraanClick here to contact me 14:13, 9 February 2017 (UTC)
  • Weak support at least enough to support a trial run of such a filter, as long as it is an alert and not a blacklisting. I think it should only be used for sources that we have frequently encountered and generally put into that unreliable category but know they have other legitimate uses that come up frequently in source discussions. --MASEM (t) 15:04, 9 February 2017 (UTC)
  • Oppose as draconian, non-specific, CENSORSHIP, and subject to widespread abuse. Softlavender (talk) 15:06, 9 February 2017 (UTC)
    • The RfC has closed. This is not the place to challenge that result. --Guy Macon (talk) 16:19, 9 February 2017 (UTC)
      • I'm not challenging that result. I am !voting on the proposal outlined in this RfC. Softlavender (talk) 16:32, 9 February 2017 (UTC)
        • You most certainly are. The closing statement is crystal clear: "An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference" You are opposing the edit filter described. --Guy Macon (talk) 18:08, 9 February 2017 (UTC)
          • To repeat: I'm not challenging that result. I am !voting on the proposal outlined in this RfC. Softlavender (talk) 18:22, 9 February 2017 (UTC)
          • Please do not challenge other users for opposing this without at least being civil about it. This is an RfC to add further restrictions to The Daily Mail, not something to reverse any restrictions made recently. --Super Goku V (talk) 06:51, 10 February 2017 (UTC)
  • Support, It will immediately cue editors into the fact that the Daily Mail is unreliable, something which is not generally obvious to editors who don't live in the UK. Most editors attempting to add a Daily Mail citation that are warned in this way would simply go get a different more reliable source to replace it (this is good for the wiki). If no such source exists, then the material likely shouldn't be included anyway (also good for the wiki). As for claims of this being censorious, a recent RfC concluded with a consensus that the DM does not meet wikipedia's requirements for a reliable source, as such, why should we not stop people adding links to it as sources? Note that I oppose 'prevention', or a 'disallow' setting (even The Onion will need to be sourced from time to time when used as a primary source). I also think that a comment about "source X may be useful in Y or Z circumstances" (as outlined in the relevant RfC ruling for that source). InsertCleverPhraseHere 15:18, 9 February 2017 (UTC)
  • Tend to oppose for three reasons. First, I don't believe the original RFC had sufficient attention and I suspect it may well be overturned or regretted before too long. Secondly, I would be reluctant to make the philosophical step that you identify in making source management a technological task rather than a human one, for all kinds of reasons (but mainly because of unanticipated effects on e.g. new users). Third, if we are using technology to police sources, we ought to start with sources that have close to 100% rejection not somewhat debatable ones like the Mail. The Land (talk) 15:20, 9 February 2017 (UTC)
    • More thoughts: Actually I am coming round to the idea of something like this in principle. I can't see any unanticipated downsides in using "log" or "tag", and either would facilitate speedy review of potentially poor sources being added. Equally, I hope we can all agree that "disallow" would be considerable overkill (as there's certainly no consensus that any of these sites should be absolutely banned from mention on Wikipedia). I still have some concerns over "warn" because generally automated messages don't work very well for new/infrequent editors (a point usually neglected in on-wiki discussion of what to say to new/infrequent editors who aren't getting things right). Still have concerns about points 1 and 3. The Land (talk) 22:03, 9 February 2017 (UTC)
  • Oppose We are supposed to be editors. If editing is so easy that it can be done by scripts instead, we would not be needed. Andy Dingley (talk) 15:24, 9 February 2017 (UTC)
    • That argument could be used against any of the edit filters, vandalism-reverting bots, etc. TigraanClick here to contact me 16:04, 9 February 2017 (UTC)
      • Only if you equate editors with deliberate vandals and spammers. Andy Dingley (talk) 18:56, 9 February 2017 (UTC)
        • So it is your considered opinion that most editors who attempt to use a source that results in an edit filter warning are deliberate vandals or spammers? I myself have on occasion triggered such a filter -- fooled by a source that appeared to be legit -- so am I a deliberate vandals or a spammer? --Guy Macon (talk) 16:33, 12 February 2017 (UTC)
  • Ignorable Oppose (because I guess the ship has sailed). A trial run of an edit filter of the Daily Mail was discussed in 2011. Elsewhere on the same page Jimbo Wales says he likes use of Pending Changes. Peter Gulutzan (talk) 15:26, 9 February 2017 (UTC)
  • Support what I understand Tigraan to be actually asking: that if a community discussion results in a consensus that a particular source should not be used, then an edit filter can be employed to enforce that consensus (to log, tag, warn or disallow, as decided). In other words, an extension in the use of the edit filter system from mainly stopping vandalism to helping enforce community consensus about sources is OK. (IIRC the problem of only being able to have a very limited number of active filters has been solved.)  —SMALLJIM  16:05, 9 February 2017 (UTC)
    • Rereading the question, he said "prevent", which means disallow. The RfC already decided "yes" to warn, and the documentation for edit filters recommends first setting up a filter to log before allowing it to tag, warn, or disallow. --Guy Macon (talk) 18:41, 9 February 2017 (UTC)
  • Support warning, oppose "preventing", with detailed proposal. Detailed proposal: create an edit filter for *.dailymail.co.uk, *.mailonsunday.co.uk, and any other Daily Mail domains that are discovered during this RfC. Set the filter to log until the end of February, tag until the end of March, and warn starting April 1st. --Guy Macon (talk) 16:14, 9 February 2017 (UTC)
  • Oppose until such time as it is shown that an edit filter can be sufficiently nuanced as to handle cases covered by the RfC's closing statement in "The Daily Mail may have been more reliable historically, and it could make sense to cite it as a primary source if it is the subject of discussion.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 9 February 2017 (UTC)
  • Oppose WP:RS states that "Proper sourcing always depends on context; common sense and editorial judgment are an indispensable part of the process." A crude mechanical filter is therefore not appropriate. Andrew D. (talk) 17:40, 9 February 2017 (UTC)
    • Thank you for noting this. I agree 100%. Softlavender (talk) 17:43, 9 February 2017 (UTC)
  • Oppose for most bad sources there is still significant proper use. There are some really bad cases which can be handled by XLinkBot or even a spam-blacklist for extreme cases. --Dirk Beetstra T C 18:40, 9 February 2017 (UTC)
    • @Dirk Beetstra So, like me, you oppose a 'disallow' setting. What is your opinion on the 'warn' and other lighter settings? InsertCleverPhraseHere 00:11, 10 February 2017 (UTC)
  • support a filter to provide a warning along the lines that "The source X has been generally found to be unreliable by the community. Please find a better source" or the like. The devil-detail is whether it should refuse to save or allow the edit to be saved after the warning is given. Jytdog (talk) 22:16, 9 February 2017 (UTC)
    • Note that in the close of the Daily Mail RFC, we intended the edit filter to warn editors, but not disallow edits. This was a very intentional decision, and I hope the wording reflects that clearly. Tazerdadog (talk) 01:36, 10 February 2017 (UTC)
  • Support It is not a suitable source. We have lots of non suitable sources that are of no encyclopedic value. For us to become a good reference we need to use higher quality references ourselves. This is one of the success of WPMED, we require high quality sourcing for medical content. The bar needs to be raised in many other areas and this is an excellent move in that direction. It will also have deal with undisclosed paid editing. Doc James (talk · contribs · email) 01:46, 10 February 2017 (UTC)
  • Support, although I would recommend two different ones, one for warning if a source is unreliable, and one for disallowing if the source is entirely unusable. -- Iazyges Consermonor Opus meum 04:09, 10 February 2017 (UTC)
  • Oppose - There is no complete ban on The Daily Mail and this should not be used to make one without consensus. To quote, "The Daily Mail is actually reliable for some subjects." These subjects might be few, but they would be suitable to use as a citation. Additionally, the amended text is not needed as the RfC also contained the following quote, "An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference." --Super Goku V (talk) 06:48, 10 February 2017 (UTC)
    • Amended - The basis for why I oppose this is in bold. "Should edit filters be used to prevent citing sources deemed unreliable..." If this RfC is about adding a filter that only warning about a specific reference, then it is misleading to me to see the word prevent used. --Super Goku V (talk) 10:11, 10 February 2017 (UTC)
  • Support friendly note Seems like some of the "Oppose" votes are confused. Nobody is proposing a "ban." Just a friendly note encouraging better sourcing. I wouldn't even call it a "warning." Certainly not a "ban." Similarly, I'm waiting to hear confused shouting of WP:WPNOTCENSORED. First Light (talk) 07:34, 10 February 2017 (UTC)
    • I suggest you read the question that is asked; which is not what you assert it to be. Nonetheless, were you correct, my oppose would stand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 10 February 2017 (UTC)
  • Support friendly warning. We should absolutely have an edit filter to nicely warn editors that a certain source is not considered reliable, and should not be cited except under unusually compelling circumstances. But I think it is essential that sources can only be added if there has actually been a consensus the source is unreliable, such as with the Daily Mail. Someguy1221 (talk) 08:06, 10 February 2017 (UTC)
  • Support 'warn', not ban. As there is some wiggle room in the closing statement that the Mail can be used in some circumstances, a warning would be more appropriate than a complete ban. - The Bounder (talk) 05:45, 11 February 2017 (UTC)
  • Support warning, there is no absolute ban, but there is reason to warn or inform. -- Alanscottwalker (talk) 10:59, 12 February 2017 (UTC) Also, support log. Alanscottwalker (talk) 12:07, 12 February 2017 (UTC)
  • Support warn, absolutely oppose ban. Our existing edit filters that rule against various URLs are already a problem too often (working around them, legitimately per WP:IAR when they're blocking something they should not, can be difficult and time-consuming). It cannot work here because something nutty, like a white-supremacist or alien-abductions newsletter, is not reliable about external facts, but remains a valid source (per WP:ABOUTSELF and WP:PRIMARY) for quoting the exact wording of statements made by their writers, interviewees, etc. I do support a warning popping up, and the edit filter creating a log, so that less fake news and WP:FRINGE gets cited and so that when the filter's warning is ignored, other editors can review the material programmatically.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  11:43, 12 February 2017 (UTC)
  • Support warn and tag, but not disallow. By tagging, we will allow fast review of potentially poor sources, but even traditionally unreliable sources may need to be used occasionally, as I believe several editors mention above, so some level of editor discretion on this is appropriate. Gluons12 | 15:40, 18 February 2017 (UTC).
  • Support warn, oppose disallow because there are legitimate uses of the DM (e.g. on the article about the DM and as a source for statements it makes). Thryduulf (talk) 09:49, 19 February 2017 (UTC)
  • Strong support for logging and maybe tagging so that we can monitor the use of the Mail as a source. The RfC is hardly an epiphany; we've known for a long time that the Mail is generally not a good source and it makes sense to examine where it is used (especially on BLPs) because it's a red flag that there could be problems with that article. I might mildly support warning, as long as the "warning" was friendly and informational rather than accusatory. I absolutely oppose disallowing, for reasons that should be obvious to anyone who has ever done nay serious article work: bashing the Mail is fun, but there are circumstances (albeit limited circumstances) where its use is appropriate. I would add that this should be expanded to cover other sources, particularly tabloid newspapers; I'm not sure why we're singling out the Mail over any other publication. HJ Mitchell | Penny for your thoughts? 14:47, 19 February 2017 (UTC)
  • Support warning for any source we generally regard as a non-RS. There's no good reason to single out the DM. SarahSV (talk) 15:24, 19 February 2017 (UTC)
  • Maybe A few things... Edit filters cannot go off of an external list of URLs or what you. Any addition will require the assistance of an edit filter manager. If we want to just warn or log the use of the Daily Mail as a source, that we can do, but adding more and more sources, indefinitely, will be become a problem. For instance, you'll probably want to say something like "the (insert name of source) is not reliable, please find a better source". A shared filter will not be able to fill in the "insert name of source", instead it will have to say "one of the sources you added", which is not acceptable in my opinion as it would be up to the editor to figure out which source the filter is talking about. Creating a dedicated filter for each source just isn't feasible. Our modern machinery means edits usually go through pretty fast, but you have to think ahead. The filters add up, especially when targeted against a wider audience. For this filter we'd likely want to target all users, which means the filter will meet at least 1 condition for every single mainspace edit. Multiply that times however many filters we create... I don't think this RfC is a bad idea, but I'm not sure a filter is the right solution. The biggest question with filters is "does the benefit outweigh the expense", here I don't think it would, unless we target only a few sources. Instead consider the versatile User:XLinkBot, or the spam blacklist if you intend on disallowing the addition of certain sources altogether MusikAnimal talk 16:19, 19 February 2017 (UTC)
  • Support "tagging" and (polite) "warning" , strongly oppose "disallowing". It's absolutely not necessary to disallow this and also very impractical as their maybe valid exceptions under rare circumstances to cite DM. This has been properly established in discussions elsewhere. We don't need dictatorial measures but useful mechanisms that remind people of the guidelines which we trust they will implement in good faith. Mootros (talk) 11:03, 6 March 2017 (UTC)
  • Support (conditional) Log, tag and warn. No disallow. If EF throws too many hits and DM is used as a primary source often (you know, in sections like Conspiracy theories and Speculation), I suppose we can do away with the warn. I do not see any need for people adding unreliable sources in <ref> to articles, do you? --QEDK () 04:21, 17 March 2017 (UTC)

Point of order

The decision at Wikipedia:Reliable sources/Noticeboard#Daily Mail RfC, ratified by five uninvolved administrators, clearly states "An edit filter should be put in place going forward to warn editors attempting to use the Daily Mail as a reference." This RfC cannot be used as a backdoor method of overturning that RfC by not having any edit filter. Tigraan made that clear when he posted this RfC, but some editors here are ignoring him --Guy Macon (talk) 18:08, 9 February 2017 (UTC)

@Guy Macon: While I can't argue that the closing statement does indeed say that, from what I can tell 2 (and a half) users fully supported an edit filter, and a further two supported it on the condition that a separate RfC was run first. This guideline states that "If a filter is designed to catch good faith edits it should not be placed in disallow mode without an appropriate consensus." I don't believe two editors to be sufficient consensus. Sam Walton (talk) 18:58, 9 February 2017 (UTC)
There were 6 editors in the RfC who supported the use of a filter, either implicitly or explicitly, and no opposition. Sunrise (talk) 19:48, 9 February 2017 (UTC)
We have a standard procedure that anyone can follow if they believe that the five closing administrators got it wrong. Posting on talk:Edit filter is not on the list and will not change the result. The standard procedure is:
  1. Post a polite query on one or more of the closing admin's talk pages, making your case and asking them to reconsider. Wait until they reply or several days have gone by. This may result in them changing the closing summary.
  2. Post a polite query on WP:AN (Not WP:ANI) making your case and asking for more uninvolved administrators to review the close. A general consensus among the administrators that the closers got it wrong will result in either the closing admins changing the result or (rarely) the closing being stricken and new uninvolved administrators being chosen to re-close the RfC with a new closing summary.
  3. Wait at least six months for the consensus to change and post another RfC.
It is a standard feature of RfCs that, barring a successful challenge as described above, everyone is required to abide by the language in the closing summary. The goal is to end the dispute. A limited amount of re-evaluating the !votes and complaining about the closing admin(s) getting it wrong is expected, as long as the result as it is written is obeyed. Extensive or prolonged complaints are generally treated with a warning then a block. --Guy Macon (talk) 21:03, 9 February 2017 (UTC)
Well, the RfC throws up a whole bunch of issues, which aren't limited to "was the RfC closed correctly", and many of which were scarcely touched on in the RfC discussion. Probably more helpful for people to keep talking about them, than to insist the subject is closed? The Land (talk) 21:34, 9 February 2017 (UTC)
I have the same feeling that the current participation seems to re-argue the previous RfC - note however that some support !voters are equally guilty of it too.
However... there has been complaints about WP:LOCALCONSENSUS before I opened this. I realize that some !voters here might have understood the logic of the premise (if banning a source is appropriate then would an EF be appropriate to do so) but decided to !vote against the premise because otherwise their !vote could have been construed as an acceptance of the previous RfC result. TigraanClick here to contact me 19:24, 9 February 2017 (UTC)

Point of order 2

The proposal has been modified after several people !voted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:41, 10 February 2017 (UTC)

Proposer's remorse suddenly strikes

Suddenly, I am having doubts about this RfC. The correct order to handle the whole thing would have been (1) establish policy for the "list of bad sources", (2) establish policy for edit-filtering those sources, (3) establish the Daily Mail fail under this, and to stop at any point were consensus fails.

The previous RfC mixed up all three, and was debated about half on point (3), half on point (1) and epsilon-esquely on point (2). In opening this RfC, I hoped to clarify point (2); but I missed in doing so that point (1) was not settled by the previous RfC, in view of WP:LOCALCONSENSUS complaints.

Should the present RfC be put on hold, conditional on a first RfC on point (1) (which may or may not overturn the previous one)? I would boldly do so, but it would look like a textbook example of unilateral action when things are not going "your" way. TigraanClick here to contact me 19:29, 9 February 2017 (UTC)

I don't see why we must proceed in that order. As long as you can get the participants to understand what this RfC is actually about, I don't see any reason why its validity should be dependent on your step 1. I don't think the Daily Mail case – although it precipitated the whole thing – is central here. The principle is whether edit filters should be used to help enforce future community decisions on sources that should not be used – or, in most cases, that should not be used without a clear understanding of why they are being used, which can be achieved with a customised "warn" edit filter message. (Per Wikipedia:Edit filter#Basics of usage: "warn ... the user will see a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.")  —SMALLJIM  20:45, 9 February 2017 (UTC)
The RFC should have been smaller in scope. You could have asked for a tool just to warn people about making citations to DM. Someguy1221 (talk) 01:58, 10 February 2017 (UTC)
@Someguy1221: I disagree. It is entirely appropriate for an editor to request broader consensus for the reasoning behind a specific community decision. As I understand it, the local consensus you discuss already exists. Tamwin (talk) 06:12, 10 February 2017 (UTC)
I would have agreed with you, but the RFC seems to have immediately turned into a second RFC on the Daily Mail issue anyway. Someguy1221 (talk) 07:48, 10 February 2017 (UTC)

I advise withdrawing this RfC and posting a new one with a question such as "How should we implement the decision at Wikipedia:Reliable sources/Noticeboard#Daily Mail RfC?", asking the readers to make specific proposals, and seeing if any get significant support. --Guy Macon (talk) 12:54, 10 February 2017 (UTC)

I disagree on that point. I believe that the closing statement should be followed and that we only add an edit filter to note a citation from The Daily Mail. It does not make sense to me to continue to attempt to ask for more penalities on sources like The Daily Mail without even enforcing the current set. --Super Goku V (talk) 19:20, 10 February 2017 (UTC)
Did you mean warn when you wrote "note"?
  • The strongest setting is disallow. In this case, the edit is rejected, and the user will see this. (A link is provided for reporting false positives.) It is also possible to have a user's autoconfirmed status revoked if a user trips the filter.
  • The next lowest setting is to warn. In this case, the user will see a customisable message that the edit may be problematic. The user then has the option to either proceed with the save or abandon the edit.
  • The next lowest setting is to add a tag. In this case, the edit is tagged for review by patrollers.
  • The lowest setting is to log the edit. In this case, the edit is merely added to the AbuseLog.[16]
The RfC specifies warn. "note" sounds like you meant add a tag or log the edit. --Guy Macon (talk) 21:38, 10 February 2017 (UTC)
If the setting is formally called warn, then that was my intention. Either way, I do believe that we should make and enforce the already closed RfC before holding more on the subject. --Super Goku V (talk) 02:48, 11 February 2017 (UTC)
Any filter editor can be bold and make the filter just for DM, regardless of the local consensus here. I would recommend warn and tag, with an informative warning, and make sure to grab any versions of the DM domain if there is more than one. Someguy1221 (talk) 03:19, 11 February 2017 (UTC)
Note The warn action will usually break bot (writeapi) edits as well (why most warn rules exclude bots). — xaosflux Talk 16:03, 19 February 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Edit_filter/Archive_7&oldid=819053475"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia_talk:Edit_filter/Archive_7
This page is based on the copyrighted Wikipedia article "Wikipedia talk:Edit filter/Archive 7"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA