Misplaced Pages

Revision as of 20:45, 3 July 2019

• WP:EFR
• WP:EF/R
• WP:FILTERREQ

This page can be used to request edit filters, or changes to existing filters. Edit filters are primarily used to address common patterns of harmful editing.

Private filters should not be discussed in detail. If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details to wikipedia-en-editfilterslists.wikimedia.org.

Otherwise, please add a new section at the bottom using the following format:

== Brief description of filter ==
*'''Task''': What is the filter supposed to do? To what pages and editors does it apply?
*'''Reason''': Why is the filter needed?
*'''Diffs''': Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.
~~~~

Please note the following:

• Edit filters are used primarily to prevent abuse. Contributors are not expected to have read all 200+ policies, guidelines and style pages before editing. Trivial formatting mistakes and edits that at first glance look fine but go against some obscure style guideline or arbitration ruling are not suitable candidates for an edit filter.
• Filters are applied to all edits. Problematic changes that apply to a single page are likely not suitable for an edit filter. Page protection may be more appropriate in such cases.
• Non-essential tasks or those that require access to complex criteria, especially information that the filter does not have access to, may be more appropriate for a bot task or external software.
• To prevent the creation of pages with certain names, the title blacklist is usually a better way to handle the problem - see MediaWiki talk:Titleblacklist for details.
• To prevent the addition of problematic external links, please make your request at the spam blacklist.
• To prevent the registration of accounts with certain names, please make your request at the global title blacklist.
• To prevent the registration of accounts with certain email addresses, please make your request at the email blacklist.

Archives

Index Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19 Archive 20 Archive 21

This page has archives. Sections older than 14 days may be automatically archived by ClueBot III when more than 8 sections are present.

Non-autoconfirmed user rapidly reverting edits

Just a note: it probably would be more useful if this filter, once triggered, would block further instances around the same time the bot reports to AIV for triggering the filter 5+ times instead of simply logging while allowing further disruption. It can take 20 minutes and over before derp revert vandals get blocked while a small army of patrollers must remain active to revert each edit, which appears suboptimal (i.e. see the still-ongoing 114.17.235.146). Thanks, —PaleoNeonate – 02:52, 1 October 2017 (UTC)

So disruption persisted for 34 minutes for this IP address alone. —PaleoNeonate – 02:58, 1 October 2017 (UTC)

29 minutes before 46.150.88.31 was stopped/blocked. —PaleoNeonate – 04:04, 1 October 2017 (UTC)

• I'd support this for a trial period. Checking the last 500 times this filter fired, just a handful of the Ips that triggered it are not blocked as of now. Crow 19:16, 1 October 2017 (UTC)

Refspammer

• Task: Prevent additions of text referencing Maximiliano Korstanje, (including, e.g., Korstanje, M. E.), or thana\s?(tourism|capitalism) (case insensitive, obv).
• Reason: Years of self-promotion and refspamming by the subject (who also created an article on himself, now deleted and salted). Recent example: . I'm pretty sure this would fit into some existing filter, but my RegEx-fu is not strong enough. Guy (Help!) 22:58, 25 February 2019 (UTC)

Preventing blank speedy contesting

• Task: Disallow edits that consist of creating a talk page with the default This page should not be speedily deleted because... (your reason here) --~~~~ text generated by the "contest this speedy deletion" button of every {{db-xxx}} template
• Reason: New users frequently believe that just clicking the button is sufficient to contest a speedy deletion, just creating the default text without further information. The filter could prevent this by requiring the default text to be modified before saving (or by requiring that "(your reason here)" is not on the page). Regards SoWhy 08:15, 27 February 2019 (UTC)

  @SoWhy: Perhaps an edit intro might be worth trying first? Something along the lines of Template:Falsepositive/Editintro or Template:BLPN notice, but perhaps larger and more eye-catching. If you want to get really fancy, it could even be customized for each speedy category, unlike the filter warning. Suffusion of Yellow (talk) 02:10, 28 February 2019 (UTC)

  Good idea (which someone already had in 2011 but was never implemented). That said, I see no problem with having both an edit intro and a filter preventing empty contentions. Regards SoWhy 08:55, 28 February 2019 (UTC)

  @SoWhy:  Done as 968 (hist · log) (log-only for now). My initial reaction was that a filter would be BITEy (WP:HNST etc.), but on second reflection deleting the page when they think they've contested it is even BITEier. Even if we don't implement the warning, the filter can be used to gather data on the effectiveness of the editintro, so can you hold off on implementing it until the filter has been confirmed as working, for a few days? The filter needs to account for all the Special:Prefixindex/Template:Hangon variations, and all the, um "creative" places the user might put their request, so may need more work. Suffusion of Yellow (talk) 01:47, 1 March 2019 (UTC)

  @Suffusion of Yellow: Thanks! Seems to work for this edit. I proposed the change to {{db-meta}} at Template talk:db-meta and I'm waiting for feedback anyway before editing a template that affects thousands of pages. Regards SoWhy 08:10, 1 March 2019 (UTC)

  @SoWhy: Looks like it was missing Template:Hangon preload A7. I've also temporarily set 1 (hist · log) to log all edits with a summary containing "Contested deletion", to see what others 968 (hist · log) might be missing. Suffusion of Yellow (talk) 19:26, 1 March 2019 (UTC)

  Still only one hit. 1 now just looking for "your reason here" instead, because there seems to something buggy with the summary check. Suffusion of Yellow (talk) 16:51, 3 March 2019 (UTC)

@SoWhy: I've disabled the filter until we decide what to do. It's probably skipped over a few because of the edit summary bug, but that should be most of them. Looking through the hits, do you see anything that's not completely hopeless on the (deleted) pages? That is, would there be any point to a warning, other than to encourage the user to write a message that will be ignored anyway? I'm curious. Suffusion of Yellow (talk) 01:43, 6 April 2019 (UTC)

Common Vandal Summaries filter

Task: Log edit summaries according to I? ?((ypo)? ?ix(ed)? ?? ?(ome)? ?(ypo(es)?s?|rammar)?|dded ? ?(ome)? ?(inks?|ontent))

Reason:Building on the request above, maybe it's a good idea to have a log-only(do nothing), or possibly tag filter for common edit summaries used by vandals. People could patrol that as a further refinement on the existing maybe bad edit recentchanges filter. 19:42, 28 February 2019 (UTC)

@Username Needed: I like the idea of a log-only or tagging filter for generic vandal summaries; I'm kind of surprised we don't have one already. I'd also add "made it better" and some of the milder ones that were taken out of 384 ("lol", "blah", "crap", "was here", etc.). But I'm hesitant to name it "Common Vandal Summaries" for something as innocent as "Fixed a typo". Can you think of a better name, that won't offend people when it shows up in their filter log after they fix an actual typo with the summary "fixed a typo", but still hints to patrollers why it was logged? Suffusion of Yellow (talk) 17:19, 3 March 2019 (UTC)

• Maybe just "Common Summaries" or "Common edit summaries"? 19:34, 3 March 2019 (UTC)

• Actually "Stock summaries" may be a good name. 20:19, 3 March 2019 (UTC)

• @Username Needed:  Done, as 970 (hist · log), with your suggestions. I suspect there will be way to many FPs for this to be useful, but it's worth a try. It also might be possible to refine based on edit_delta, e.g. only log "added content" when the size decreases, etc. Suffusion of Yellow (talk) 23:08, 3 March 2019 (UTC)

  Suffusion of Yellow, FYI, there's some overlap here with 633 and the "canned edit summaries" tag. Gaelan 💬✏️ 05:06, 4 March 2019 (UTC)

• @Gaelan: It should exclude anything that already hit 633. I'm not seeing anything here that hit both. Suffusion of Yellow (talk) 07:23, 4 March 2019 (UTC)

  Suffusion of Yellow, There's no need to check user_mobile == 1 is there? Since 633 now only checks user_app == 1 Galobtter (pingó mió) 09:58, 4 March 2019 (UTC)

  @Galobtter: Thanks, removed the check. The mobile web interface does suggest "Example: Fixed typo, added content", but the user still needs to manually type them in. Suffusion of Yellow (talk) 17:28, 4 March 2019 (UTC)

• I took a sample of the most recent 20 edits and got a 35% FP rate (or 25% if you count non-disruptive edits with misleading summaries). 12:38, 4 March 2019 (UTC)

• Most FPs (all bar 1) had an edit delta of <10. Maybe that could reduce the amount of FPs? 12:42, 4 March 2019 (UTC)

• @Username Needed: Thanks! Some more data. Suffusion of Yellow (talk) 19:51, 4 March 2019 (UTC)

• I've looked through some of the "Added content" section of the data dump and it might be useful to exclude anything that adds a <ref> tag. That should also reduce the FP rate considerably. (Although it depends on whether you think that adding unsourced information should be excluded or not, otherwise it removes a much smaller amount) 09:02, 5 March 2019 (UTC)

• Since we seem to be using this to monitor, I've put a noarchive on this in case any of us go on a wikibreak. 09:08, 5 March 2019 (UTC)

@Username Needed: So. I think I see what's going on here. That vast majority of hits are for exactly (up to capitalization) the phrases "added content" and "fixed typo". So it's not so much a case of sneakiness, but laziness. The mobile web site suggests Example: Fixed typo, added content so that's what people are typing when they think they have to type something there. Either that or I have much narrower definition of "typo" than most people. Anyway, I've disabled the filter for now while I think about this. 3700 hits is enough data. I'm wondering if instead MediaWiki:Mobile-frontend-editor-summary-placeholder could use some refinement. Suffusion of Yellow (talk) 20:29, 10 March 2019 (UTC)

@Username Needed: I've re-enabled it for now, with some edit_delta checks. We have other filters that check for unreferenced content, so I'm only logging "Added content" when the edit_delta <= 0. For "Fixed typo", I've gone with your suggestion of only checking edit_delta > 10 | edit_delta < -10. I've also created 981, named, in fact, "Common vandal summaries". Right now it's just checking for the word list from 384. See Misplaced Pages:Edit_filter/False_positives/Archive_96#149.135.11.157 for why it was removed from that filter.

@Galobtter: In that thread you mentioned some stuff from other filters. Since the 981 is not disallowing yet, now would be a good time add anything you had in mind. Suffusion of Yellow (talk) 01:31, 6 April 2019 (UTC)

Hmm, I don't remember what those filters were; as a sidenote, you need !summary rlike ("\

I think that 981 can be set to tag - I just looked through the first 50 and found only 3 FPs - 2 of which were issues with lol (which may have to be removed from this filter) 20:21, 1 July 2019 (UTC)