Wikipedia talk:Edit filter

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

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

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 work • What'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 work • What'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 [1] 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)

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)

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)

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 (contribs • talk) 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 (contribs • talk) 18:28, 30 December 2015 (UTC)

I believe there's been three types recently.[2][3][4]. 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)

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)