Wikipedia talk:Edit filter

Adding abuse-filter-view-private into sysop package

Resolved

 – "Committed with adjustments in r52743." (per Andrew Garrett). Not sure when this will be live, but it's on the way. –xeno^talk 14:31, 3 July 2009 (UTC)

was: Rolling AFE into +sysop redux

Previous discussion: Wikipedia talk:Abuse filter/Archive 3#Straw poll

While I was originally unreceptive to the idea, now that we've settled into the AFE, I think we should roll it into the sysop bundle. Especially so that admins who just want to view private filters (like me =) don't need to add themself into the usergroup. However, please see arguments contra in the last discussion, especially from slakr who does have some compelling reasons against. Thoughts? –xeno^talk 01:06, 23 June 2009 (UTC) Changed my position to just add af-view-private to +sysop - vote for the bug below. –xeno^talk 14:00, 24 June 2009 (UTC)

I tend to agree with the previous decision- don't enable by default, as admins can turn it on for themselves. If there was a bit for "view only" and another for "edit and break the whole encyclopedia", I might agree to roll it in to the bundle. However, as it's just one bit, causing interested admins to flip the bit isn't much work. tedder (talk) 05:17, 23 June 2009 (UTC)

There is bugzilla:19362 now that requests a new right for reviewing private filters without being able to edit them. I think we should let the devs create such a right and roll it into the sysop bundle (or maybe even rollbacker, see haz's suggestion at AN) and leave the editing right a separate permission. Regards SoWhy 12:56, 23 June 2009 (UTC)

That would preclude this suggestion and is a better idea altogether - though I don't think it should be included in rollbacker by default; otherwise the pool of individuals who could leak filter details would be too great. It's not tough to get an admin to enable rollback for you. –xeno^talk 16:20, 23 June 2009 (UTC)

Agreed, but may be discussed. My original suggestion of this at AN (which lead to the bugzilla) was because admins like you and me might want to view the filter but not tamper with it. On a side note (see section above as well), if this flag gets created, the abuse filter group should not be given out lightly without any process, seeing that it would allow non-admins to perform admin tasks. We might want to open up a discussion on this at VPP or similar to discuss some kind of system to set this flag. Regards SoWhy 17:08, 23 June 2009 (UTC)

Vandals have managed to get rollback rights quite a few times, it's very easy. I think the abusefilter-view should be bundled with admin, as we have no need for non-admin users with view permission without edit permission. Cenarium (talk) 21:46, 23 June 2009 (UTC)

I would support abusefilter-view-private rights to be added to the sysop user group, and for the AFE group to be kept as-is. haz (talk) 13:54, 24 June 2009 (UTC)

I've changed the heading of this thread; this is a better idea all around. –xeno^talk 13:57, 24 June 2009 (UTC)

I support Xeno's original proposal, i.e. add all the AFE userrights into the admin usergroup. There is really no point in separating a userright which a usergroup can give to themselves anyway. Admins have been shown to have the trust of the community, and so we have to trust them not to edit a filter if they don't understand what they are doing! — Martin (MSGJ · talk) 14:18, 24 June 2009 (UTC)

I've been an admin for 2½ years and wouldn't have a freaking clue when it comes to technical stuff like that :) However, I'm in agreement that the view attribute, with read-only access effectively, should be added to the package. Alternatively, I like Tedder's suggestion near the top of this section - enable it for all, but only those who care can switch it on. Orderinchaos 16:21, 24 June 2009 (UTC)

Thanks. And the read-only makes it MUCH easier- give all sysops readonly, allow them to turn on full rights if they want it.

But with read-only, what is the non-admin policy going to be? I.e., give read-only access to most who ask for it, and be picky with full rights to nonadmins? Or absolutely no full rights to nonadmins? tedder (talk) 16:37, 24 June 2009 (UTC)

I don't see a need to have the ability to grant view-private rights to non-admins. If the non-admin wants to work with filters they should probably just apply for full access. If they're not competent enough to write filters, there's no real need for them to view private ones. –xeno^talk 16:42, 24 June 2009 (UTC)

That's also my opinion, there's no need for non-admins to view private filters if they don't have the full access. Admins however, with edit permission or not, should have the read permission by default, as they often have to view filters for information, for example for User:Mr.Z-bot reports at WP:AIV. Cenarium (talk) 19:10, 24 June 2009 (UTC)

I do see a need for a grantable right from my perspective: As a sysop at a smaller sister-project[1] who works with the AbuseFilter there, it would be very helpful to be able to view and export filters that have been developed by the larger community here. This is particularly so because the extension's documentation is so sketchy that it is difficult to make much headway without studying examples, even for one whose programming career is longer than the age of the typical Wikipedian, unless one has specific experience with MediaWiki or PHP. ~ Ningauble (talk) 19:36, 24 June 2009 (UTC)

Most filters aren't private, filters are 'privatized' when dealing with serial vandals or sockpuppets active on this wiki. So there shouldn't be many cases where they'd need to be imported to another wiki. There are also safe off-wiki ways to transmit information if needed, but it doesn't warrant a new userright imo. Cenarium (talk) 20:30, 24 June 2009 (UTC)

Furthermore, if there was a demonstrated need then I'm sure the community would be willing to grant (even if temporarily) +AFE to the admin-on-another-project for view-only purposes. –xeno^talk 20:37, 24 June 2009 (UTC)

Early on, when the extension was first rolled out, a greater proportion were private, which made the learning curve rather steep for those not privy to this community's accumulating knowledge. This is no longer a problem now that most are visible. ~ Ningauble (talk) 15:24, 19 July 2009 (UTC)

Request for name change

Could the name of this log be changed, please? I just noticed the other day that I have entries in an "abuse" log for linking to YouTube and for creating articles about Michael Jackson, which triggered a suspicion of vandalism. A few other people are voicing the same concern at AN/I, and someone suggested posting the request here. SlimVirgin ^{talk|contribs} 18:11, 2 July 2009 (UTC)

• I would support a name change on all public-facing parts of this extension to "Edit filter". Even after we tell people that "Entries in this list do not necessarily mean the edits were abusive.", they still worry about poisoning of their well. –xeno^talk 18:14, 2 July 2009 (UTC)

I too support the name change. As I have commented before: The current name is arguably inaccurate (since it doesn't contain any possible, probable qualifiers) and counter-productive in that it can drive away good faith editors who see their good edits labeled as "abuse". Vandals surely don't care what we call their edits, only good faith editors are likely to be sensitive about their reputation. Abecedare (talk) 18:24, 2 July 2009 (UTC)

Actually, that would be a sensible thing to do. I hadn't thought of it, but indeed a more neutral and less bitey title would be useful, and it would not in any way change the function of the extension. Good idea! --Jayron32.talk.contribs 18:41, 2 July 2009 (UTC)

I changed the name of the log to "Edit filter log". Ruslik_Zero 19:30, 2 July 2009 (UTC)

Thank you, User Ruslik0. User SlimVirgin, you should spend more time at AN/I offering solutions. I don't know why so many wikipedians offer the, "it doesn't bother me to have an abuse filter" defense when there's no point in calling it an abuse filter while denying it is one.

Just for that I'm going to continue editing the garbage created by anybot. Probably only these 900 articles plus maybe a few thousand redirects to delete. --69.226.103.13 (talk) 06:24, 3 July 2009 (UTC)

I changed all system messages. The only remaining steps are moving this page to Wikipedia:Edit filter and changing the name of user group to (I propose) Edit Filter managers. Ruslik_Zero 09:08, 3 July 2009 (UTC)

I did the move; it was a bit of a monster. I'll hold off on fixing the double redirects for a few hours in case all hell breaks loose again... Happy‑melon 18:56, 7 July 2009 (UTC)

We could actually get the special page itself renamed using $aliases['en']['AbuseFilter'] = 'EditFilter'... Worth a site request? Happy‑melon 19:14, 7 July 2009 (UTC)

I renamed Abuse Filter editors to Edit Filter managers. I think Wikipedia:Edit_filter/Performance page needs attention, because it is updated by a bot. The main page itself (Wikipedia:Edit_filter) should be edited to reflect the change in the name of the filter. Ruslik_Zero 19:23, 7 July 2009 (UTC)

Quite happy to see we're removing the word "abuse." --MZMcBride (talk) 19:23, 7 July 2009 (UTC)

Template:Bug Happy‑melon 16:34, 9 July 2009 (UTC)

Hindsight

Well, they say it's always 20/20. I think "ActionFilter" is better for a number of reasons:

1. Filters (as far as I'm aware) can apply to more than just &action=edit;
2. It preserves the AF initialism, which can be helpful for old discussion, shortcuts, etc.;
3. Using CamelCase keeps in line with other pages like Wikipedia:CheckUser.

I doubt anyone will want to implement this change (esp. as it was only just changed to "Edit filter"), but I thought I'd mention it anyway. --MZMcBride (talk) 23:30, 17 July 2009 (UTC)

I like it, but your conclusion is bang on. ;p –xeno^talk 04:17, 21 July 2009 (UTC)

Edit filter 23 attached tag to wrong user - really bad

This filter's heuristics are hidden, but this filter is bad. It is the one that tagged my edit as "possible vandal phrases," while it was referring to an edit made by a different user.

The edit filter should, in the very least, attach the tag to the correct editors. Really bad when it doesn't. See my edit log to find the edit, and note that the discussion and edit in the log are not mine. --69.226.103.13 (talk) 03:04, 4 July 2009 (UTC)

This would appear to be caused by an already known bug in the abuse filter. עוד מישהו Od Mishehu 07:52, 7 July 2009 (UTC)

The abuse filter is not disabled while the bug is already known? Why not? --69.226.103.13 (talk) 19:10, 7 July 2009 (UTC)

Probably because that would present a net-negative. Most editors realize that the AF EF is not perfect and that having entries in one's EF log (especially erroneously attributed ones) does not necessarily indicate they're a bad person. –xeno^talk 19:13, 7 July 2009 (UTC)

I believe that the overall number of false positives caused by this bug is relatively small. I doubt any admin would block you on the basis of an edit filter log without checking that your edits were, in fact, problematic. עוד מישהו Od Mishehu 08:59, 12 July 2009 (UTC)

Changing North America to New World is possible vandalism!

These edit filters need a work before they start recording incidents and putting them anywhere. No one reading this cares that Edit Filter 23 tags the wrong contributor, and, now, another one,[2][3] Edit Filter 11, tags the words "New World" as possible vandalism, when it's supposed to be tagging it sucks, meaning that potentially every taxon that ranges both continents will be tagged as a vandalism edit if an IP edits it.

It's supposed to tag "You/He/She/It sucks," just like Edit Filter 23 with its hidden code is supposed to tag the actual contributor of the actual edit. When things that aren't in the code start happening, it's times to stop running it and get it cleaned up.

The IP --69.226.103.13 (talk) 18:53, 4 July 2009 (UTC)

If you report false positives like this to Wikipedia:Abuse filter/False positives you may get a faster response. --Jayron32.talk.contribs 19:06, 4 July 2009 (UTC)

They're already being ignored there, but thanks for suggesting the best location. It's hard to find the right page to post on wikipedia.

I'm posting here out of a general concern for the filters, also, since these are basic bug type errors that should have been removed before running. They're also hard to understand how they could happen from the source scripts. --69.226.103.13 (talk) 19:27, 4 July 2009 (UTC)

Actually, if you have serious concerns, another place to try is to find the person who wrote the abuse filter in question, present evidence that the filter is not working as intended, and ask them to disable it until the problems can be fixed. The most direct and personal method may work. --Jayron32.talk.contribs 19:32, 4 July 2009 (UTC)

BY the way, I did find the source of the problem. Apparently, the filter tags any edit by an anon which includes the word "suck" in it; any time that article is saved by an anon, since it contains the word "goatsucker", the edit will be tagged as possible vandalism. You may want to bring this up to the person that wrote the filter; it will help them make it run better. --Jayron32.talk.contribs 19:35, 4 July 2009 (UTC)

No, only if they edit that section of that article. The tag does say 'possible vandalism' not, 'vandalism', its allowed to have a small number of false positives, as it doesn't disallow the edit. Prodego ^talk 19:58, 4 July 2009 (UTC)

But it's not 'possible vandalism' by that editor, as they're not the one adding "goatsucker" or the term "they suck" (in the same paragraph, and more likely) that tripped the filter. Suck is appropriate to describe taking in liquid through a beak/mandible modified to suction liquid.

This contributor noticed his legitimate contribution tagged as "possible vandalsim."

The filters should not tag the wrong editor, any editor who did not make the contribution. Bad enough: indiscriminate tagging, but worse: attaching it to the wrong edit. There's no reason or advantage to accept routine false positives like this in the first place. --69.226.103.13 (talk) 21:15, 4 July 2009 (UTC)

Sorry, but that tag is worse than useless. It tags revisions as "possible vandalism" when they might be, but also possibly aren't, vandalism. Anyone patrolling recent changes is going to be looking at all edits from anonymous and newly registered users anyway, so this doesn't help them; it doesn't help find vandalism any more quickly because of its high false positive rate, and it doesn't aid in project maintenance in any other way I can see. What precisely is the purpose of this tag other than to harass anonymous and newly registered users? Gurch (talk) 22:01, 4 July 2009 (UTC)

Ask whomever created the filter. Prodego ^talk 02:55, 5 July 2009 (UTC)

That would be Cenarium, who for reasons that escape me seems to think that exempting individual users is the way to go. Gurch (talk) 18:01, 5 July 2009 (UTC)

WTF? No, it's not me. BTW, it seems to have been fixed by Od Mishehu to avoid when the word was already there. And I don't think individual exemptions are the way to go, that was a temporary fix. And.. I thought you knew we don't have the resources to check all changes... Cenarium (talk) 00:19, 11 July 2009 (UTC)

Yes, it was you that added the "possible vandalism" tag. We have logs of these things. We have the resources to briefly check all changes by anonymous and newly registered users (just not to check the entirety of every revision made by them and fill out a review form for each). And even if we didn't, that is not a very good excuse to reject good changes. Gurch (talk) 22:44, 12 July 2009 (UTC)

Tags in contributions and histories and tag filter input box

I don't think it's necessary to show tags in histories and contributions. It can be problematic with false positives, and the filter log can be used for verifications, tags are really needed in recent changes, and for other functions we may have in the future, but they are no major needs to have them displayed there. There is the filter log linked in the contributions, and in histories, we could add a "edit filter log" link next to the "View logs for this page" link. Tags can also be applied to logs, see here for examples, there too, it's probably unneeded. Now the tag filter input box, do we need this ? I'm not sure it's really used, or even usable. Cenarium (talk) 00:49, 11 July 2009 (UTC)

*yawn* why are you coming up with every conceivable solution to the problem of false positives except FIXING THE FILTERS THAT CAUSE THEM. Gurch (talk) 22:47, 12 July 2009 (UTC)

I fixed or disabled several filters, removed inappropriate taggings like the Mikael Jackson and unflagged bot filters, removed warn or disallow actions for filters that ought not to have those, e.g when I removed disallow for filter 18 . But this is largely irrelevant; this is not so much about false positives, but usability. Cheers, Cenarium (talk) 14:59, 24 July 2009 (UTC)

Filters 9 and 97

What is the differences between filter 9 and filter 97? The former applies to all edits of unregistered users in the main namespace, while the latter to all large (>5000) additions to pages in all namespaces made by non-autoconfirmed users. They frequently overlap. Does it make sense to have two filters? Ruslik_Zero 16:54, 12 July 2009 (UTC)

No. Not much of the filter system we have does. Gurch (talk) 22:46, 12 July 2009 (UTC)

Filter 200, or should the EF be engaged to track non-abusive, non-"wrong" edits?

Special:AbuseFilter/200

Why on earth is there a filter looking for removed prods that is tagging edits with "tag: prod removed"? I've triggered this thing a number of times now and to be perfectly honest I can't see that it has any purpose whatsoever. This filter makes it seem as though you are doing something wrong when you remove a prod; both the tag and the filter log. If an editor wants to know if a prod they placed on a particular article has been removed then they need to watchlist said article. --Tothwolf (talk) 16:47, 13 July 2009 (UTC)

• I agree, this filter is a bad idea and is just going to cause more negative feelings about the edit filter. I've disabled it. I'm sure a bot can be written to monitor the prod category without needing a filter to help it along. –xeno^talk 16:52, 13 July 2009 (UTC)
  • See Wikipedia:Edit filter/Requested. SoWhy believes that the filter would make his bot run more efficiently. -- King of ♥ ♦ ♣ ♠ 17:10, 13 July 2009 (UTC)
    • I don't think the EF was designed to be, nor should it be, used as part and parcel of a bots' operation. However, if I am alone in this opinion I don't object to the filter being re-enabled, but I would like to see more opinion on this. At present, people who see entries in their edit filter log don't take kindly to it, no matter how much we tell them that it doesn't necessarily mean it's an abusive edit. –xeno^talk 17:12, 13 July 2009 (UTC)
      • I think the filter is useful not only for a bot (the bot in question was previously requested by another user and uses a different mechanism). But I thought we have renamed the abuse filter specifically because not all edits tagged are really abuse and so I thought consensus was by now that filters can be used for any kind of edits, not only abusive ones. I think the filter is useful to highlight the removal of prods for people who watchlist those articles as tags show up much better than simple edits (where the edit summary usually lacks this particular information). It's of course a matter of consensus whether this filter should be enabled but "negative feelings" sounds like a weak argument. The filter serves to make maintenance easier, doesn't it? So such filters cannot be negative per se just because the edits are not abusive. It's similar to Special:AbuseFilter/29 in this regard. Not all edits this filter flags are abusive but it's informative to have. Regards SoWhy 17:26, 13 July 2009 (UTC)
        • Filter 29 tags new users. This one tags all users, so we're going to have a lot of folks generating entries in their EF logs, and a lot more complaints about that. We've renamed the filter yes, but I think that was because that in looking for abuse, it sometimes tags non-abusive edits - not because we should now use it for stuff like this. As I said above, I'm prepared to be wrong on this. –xeno^talk 17:29, 13 July 2009 (UTC)
          • I, too, am prepared to admit to be wrong but I had thought that with the name change and with some filters, consensus changed on this issue. For example, filters 183 , 155 and 96 track contributions that are mostly or always good-faith and non-abusive. Regards SoWhy 17:40, 13 July 2009 (UTC)

← They track good faith contributions that are usually wrong, whereas removing prod warnings (unless you're that abusive socky guy) is almost never wrong. –xeno^talk 17:42, 13 July 2009 (UTC)

Well, adding links to YouTube is not per se "wrong", is it? People just use them too often but that does not make the edits themselves wrong or abusive and that's the point I want to make. Yes, removing prod templates is almost always correct but imho still useful to know. Regards SoWhy 17:50, 13 July 2009 (UTC)

They're usually wrong, being right is the exception. Vice-versa for removing prods, so generating a note in someone's EF log every time they do so isn't a good idea (imo). –xeno^talk 17:55, 13 July 2009 (UTC)

The Article alerts bot can track prods without needing a special edit filter in place so I don't see why another bot couldn't also do so. That said, I'm not even sure a bot is needed to notify someone of removed prods, they can just as easily add the article to their watchlist.
As for Youtube links, I'm unfortunately all too familiar with that filter as I got involved with the discussion over that one when it was extended in an attempt to track torrent links (which was later removed as it is unworkable and unnecessary). I added a valid Youtube link awhile back where a software developer was discussing software functionality. Even though that might be the "exception", and even though it is a perfectly acceptable link (actually used as an inline citation), having it show up in the log with my contribs makes it seem like I did something wrong there too. --Tothwolf (talk) 18:10, 13 July 2009 (UTC)

Odd false positives

There are a whole slew of entries for 71.191.53.234 (talk · contribs) editing on Marijuana (etymology) (edit | talk | history | protect | delete | links | watch | logs | views) when that user has not edited in close to an hour and there had not been any edits on the article in over a day. --B (talk) 04:23, 18 July 2009 (UTC)

That's correct, the edit filters are inaccurate. It has been reported edit filters can't find the edit they're tagging, but nothing was done. It doesn't matter they are creating a permanent log of nonsense. Anybot created thousands of nonsense articles that had to be deleted. At some point this nonsense will have to be handled. Meanwhile it's in the "accumulate nonsense" action phase. We could bet and try to guess the ultimate number of bad edit filters created? --69.226.103.13 (talk) 00:02, 19 July 2009 (UTC)

Maybe the filter gave a warning and the IP never saved its edits? --NE2 00:42, 19 July 2009 (UTC)

This appears to be bugzilla:19680 again. עוד מישהו Od Mishehu 09:47, 19 July 2009 (UTC)

Special:AbuseFilter/63

This filter is designed to prevent newcomers from making abusive unblock denials. I think we need a filter to prevent these, on the outside chance that the blocked user is, in fact, one who has a chance of getting unblocked - denials like this need to be stopped before the user sees them. עוד מישהו Od Mishehu 09:58, 19 July 2009 (UTC)

I'd disabled this recently because the condition limit percentage was getting rather high (above 4%, meaning 4% of all edits were not being checked for filters), the filter has had relatively few hits, and (as I said in the editor logs) any attempt to decline an unblock request is reported to #wikipedia-en-unblock on freenode. There's usually a couple dozen administrators in that channel, so any abusive denials should be reverted quickly.

That said, the condition limit percentage is now astonishingly low, less than a tenth of a percent. If this filter could be optimized (to use contains_any() or something), I've no problem with it coming back online. Hersfold ^(t/a/c) 19:04, 19 July 2009 (UTC)

Future albums

The wording of this template isn't right:

"Wikipedia has a policy stating Wikipedia is not a crystal ball. Adding details of future albums or other record releases where not even the name is known is not consistent with this policy."

WP:CRYSTAL says "All articles about anticipated events must be verifiable". It doesn't say "Articles about anticipated events are not allowed," nor does it say "Articles cannot have details of future albums". Adding well-sourced, verifiable information about future albums is consistent with WP:CRYSTAL, and this filter should make that clear. —Gendralman (talk) 14:51, 19 July 2009 (UTC)

Filter 52 - Edit summary vandalism II

The activity on this filter is dwindling down to only about 20 hits a month, and it's also prone to false positives. Is it worth the 7.63ms it takes to run? (A huge filter indeed!) -- King of ♥ ♦ ♣ ♠ 04:59, 21 July 2009 (UTC)

Any filter that takes more than 5 ms should be disabled, IMO - if an edit takes too long to process it could time out and just return a BSOD. There ought to be some way to optimize that, although I can't check right now as I'm on the wrong account. Hersfold non-admin^(t/a/c) 17:46, 22 July 2009 (UTC)

I've edited it and it's under 6 ms now, so I've reenabled. This may not get many hits per month, but it is a very important filter for dealing with a particular set of long-term vandalism. Any further ideas to reduce the runtime would be greatly appreciated. NawlinWiki (talk) 14:32, 24 July 2009 (UTC)

Special:AbuseFilter/18

Can something be done for addition (accidental or not) of a blank table, such as this:

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

I have spent the last hour going through articles that had these in them, and I still have thousands of search results to go. Could something possibly be added to Special:AbuseFilter/18 to catch the string "! header 1", "! header 2" or "! header 3", since these are unlikely to appear in constructive edits. Not sure this should be a "disallow" case, but a tag would be very helpful.-RunningOnBrains^(talk) 20:41, 22 July 2009 (UTC)

I added "! header 1" to the filter. Ruslik_Zero 13:41, 23 July 2009 (UTC)

I changed "! header 1" to "| row 1, cell 1." Header 1 might (just might) have a plausible use, while I could not think of one for row 1, cell 1, IMHO. -- King of ♥ ♦ ♣ ♠ 05:40, 24 July 2009 (UTC)

Special:AbuseFilter/212

What is the point of this filter? It's generating filter log entries for perfectly appropriate actions. Experienced users tend to edit the final section to add new sections as well. It's annoying, but doesn't warrant an edit filter. –xeno^talk 17:41, 28 July 2009 (UTC)

Experienced users are exempted by the !autoconfirmed. Also, I recently fixed this filter to remove the false positives; don't look at the ones before July 27. The point of the filter is to make sure new users add headers to their posts, either by clicking "new section" or adding "==" around the header. Yes, experienced users do edit the final section, but if new users do that along with "==", it's not going to get flagged. But what about replying to another post? That's an unavoidable false positive - but wait! It's not a false positive after all, since they're supposed to put colons before it to indent. (I know, no need to hassle over a colon, but the filter just conveniently flags those mistakes as well.) The only real false positive I've seen since the correction was users editing a subpage of their own talk (e.g. [4]). -- King of ♥ ♦ ♣ ♠ 22:18, 28 July 2009 (UTC)

I think this is an unnecessary drain and (if set to warn and/or disallow) a barrier to new users getting help. It's a minor annoyance and not something we should engage the EF on - imo. –xeno^talk 22:29, 28 July 2009 (UTC)

Then the warning should be made as friendly as possible. (Of course it's not going to be disallowed.) I think it would help both the new users (learn how to post on talk pages) and established users (not have to get confused because the post was not under a header). They're going to have to learn anyways, so why not earlier? See Special:AbuseFilter/167; isn't that "a barrier to new users" creating articles? -- King of ♥ ♦ ♣ ♠ 23:03, 28 July 2009 (UTC)

Well I guess we'll just have to wait for others to weigh in. I'm not a fan of this filter at all. Just as an aside, please do try to ensure your titles are a little more tactful, especially for a filter like this targeting good faith edits (I'm talking about the original title "New user editing user talk page", not the newer, better one). –xeno^talk 23:06, 28 July 2009 (UTC)

Seems odd that KoH disables a filter which is designed for a single article and takes barely a millisecond, but then creates this one using more than twice the CPU time for edits that cause no damage at all. I'm baffled. Wknight94 ^talk 03:35, 29 July 2009 (UTC)

Yes, I thought it was a little on the expensive side. –xeno^talk 03:44, 29 July 2009 (UTC)

But 212 gets over 20 hits a day. It's the hit/runtime ratio that counts. -- King of ♥ ♦ ♣ ♠ 04:42, 29 July 2009 (UTC)

No, it's useful hits/runtime ratio that counts. 212 is catching stuff no one cares about, i.e. 0 useful hit ratio. Wknight94 ^talk 14:04, 29 July 2009 (UTC)

(unindented) What about Special:AbuseFilter/104? Placing {{helpme}} signifies that you want help, no matter where you put it. It's just that if you put it in the main namespace, someone will have to clean up after you and find you in the history to know who put it there. (Isn't that what we have to do if someone posts on your talk page, neither adding a header nor signing?) And Special:AbuseFilter/211 is for their own good; 212 is (in addition to making it more convenient for us) also for their own good. To say that it is useless is a bit of an overstatement. Let's say that 153 gives you a small gold coin every month, and 212 gives you a dollar every hour. Which would you rather have? -- King of ♥ ♦ ♣ ♠ 16:11, 29 July 2009 (UTC)

104 prevents garbage from going in the mainspace. 211 saves people getting spammed. 212 ... what does it do? Have you been following up the logged reports and teaching users how to use talk pages? They'll learn to use talk pages eventually, there's no need for a an expensive filter. It should be disabled. –xeno^talk 16:14, 29 July 2009 (UTC)

Let's go back to the example of 167. What harm does that do? -- King of ♥ ♦ ♣ ♠ 16:24, 29 July 2009 (UTC)

According to the filter, the need to "brute forc[e] through thousands of submissions to locate [the malformed request]" . –xeno^talk 16:34, 29 July 2009 (UTC)

I also don't see much use in this filter. The edit filter really shouldn't be used to teach newbies how to use talk pages. --Conti|✉ 16:51, 29 July 2009 (UTC)

Seeing that there is no support for this EF, I've disabled it. Question: would it be beneficial to modify MediaWiki:Talkpagetext to teach them to use talk pages? -- King of ♥ ♦ ♣ ♠ 17:03, 29 July 2009 (UTC)

The first link there leads to an explanation of talk pages and the use of the same. I assume most newbies don't read stuff like this and will just do what they're planning on anyway. –xeno^talk 17:48, 29 July 2009 (UTC)

BTW, go ahead and disable Special:AbuseFilter/104 too for that matter. That looks almost as useless. And is it really taking over 7ms for that?! Unreal what my little 1ms filter is being shut off in favor of... Wknight94 ^talk 18:00, 29 July 2009 (UTC)

 Done. Was actually 9.1ms at the time of disabling. {{helpme}} templates, by their very nature, will quickly draw users to their erroneous usage. No need for a filter. –xeno^talk 13:40, 30 July 2009 (UTC)

Retrieving new wikitext for a disallowed edit from the filter log

How can we do that ? Simple copy/paste doesn't preserve spaces (and when you get interminable tables...). See here for such a request. Cenarium (talk) 04:09, 30 July 2009 (UTC)

Lamest catch ever

OMG, you're kidding? There's a filter that tags users that put an ellipsis on user talk pages! Edit filter 135 might be the lamest thing I've found on en.wiki to date.

It probably started by tagging everyone's signatures.

--69.226.103.13 (talk) 21:05, 30 July 2009 (UTC)

You've got one period too many in your ellipsis... –xeno^talk 21:07, 30 July 2009 (UTC)

No, it's an ellipsis at the end of a terminal sentence, 4 is the correct number of dots for such an ellipsis. --69.226.103.13 (talk) 06:55, 31 July 2009 (UTC)