Wikipedia:Edit filter noticeboard

Source: Wikipedia, the free encyclopedia.

This is an old revision of this page, as edited by Xaosflux (talk | contribs) at 11:42, 5 October 2017 (→‎Request for Edit Filter Helper - Dane: +links). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

    Welcome to the edit filter noticeboard
    Filter 1318 — Pattern modified
    Last changed at 15:21, 8 August 2024 (UTC)

    Filter 1264 (deleted) — Flags: disabled

    Last changed at 00:48, 8 August 2024 (UTC)

    Filter 384 — Pattern modified

    Last changed at 11:39, 7 August 2024 (UTC)

    Filter 1320 (new) — Actions: none; Flags: enabled,private; Pattern modified

    Last changed at 02:27, 7 August 2024 (UTC)

    Filter 1319 (new) — Actions: none; Flags: enabled,private; Pattern modified

    Last changed at 13:15, 5 August 2024 (UTC)

    Filter 54 — Pattern modified

    Last changed at 04:25, 5 August 2024 (UTC)

    Filter 1120 — Actions: tag

    Last changed at 03:21, 4 August 2024 (UTC)

    This is the edit filter noticeboard, for coordination and discussion of edit filter use and management.

    If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives.

    Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters.



    Edit filter helper - implementation

    Following the closure of the RfC above with consensus in favour of creating the right, I have:

    • Updated the header of WP:EFH from "proposed" to "pending" and added the {{procedural policy}} tag
      • Ideally it should have an "information page" tag at the top and "procedural policy" tag in the relevant section, but the information page tags explicitly say they are not policies or guidelines. If anyone knows how to represent this better, please change it.
    • Created a request on Phabricator for the group conferring the rights to be created - see Phab:T175684.

    Things that should be considered while we are waiting:

    If anyone has strong feelings about either of these (I don't) then I don't see a reason not to be bold. Thryduulf (talk) 13:19, 12 September 2017 (UTC)[reply]

    I think the talk page should be directed to WT:EF. Instead of being a standalone page, the content could be added under the edit filter managers section of WP:EF. -- Ajraddatz (talk) 17:11, 12 September 2017 (UTC)[reply]
    This has gone live, has been tested and is working, including the new non-admin SBL viewing. Localized labels / page directs can be updated as needed. — xaosflux Talk 21:53, 18 September 2017 (UTC)[reply]

    Publicity of filter 879, filter also affecting accounts

    Two things I want to say about this filter:

    1. Should this filter be private? It seems like it's targeting possible broken proxies, and the "Possible open proxy" filter (464) is private.
    2. I feel like this filter, since it's titled "Possible broken proxy", shouldn't be affecting accounts. Should it be limited to just IPs (replacing !"confirmed" in user_groups with user_age == 0)?

    MRD2014 Talk • Edits • Help! 23:40, 12 September 2017 (UTC)[reply]

    I think there's no reason for 879 to be private. Malforming edits with a broken proxy is fairly unavoidable - you are either using an IP which breaks articles, or one which doesn't. As far as I can tell there's no one deliberately making these edits, and if someone was trying to avoid the filter that would actually be a good thing. I've been thinking about 464, and am leaning towards thinking it should be also public for the same reasons, but I will add that it is slightly different in that it is more likely to be triggered by some long term abuse cases.[1] My preferred option is to eventually merge the filters and use a custom warning for both. As for edits made by accounts, they are affected exactly the same as the IP addresses they are using,[2][3] but there is some allowance made for the fact that established users are less likely to make these edits. -- zzuuzz (talk) 04:47, 13 September 2017 (UTC)[reply]
    I see. The word "proxy" in the description confused me. —MRD2014 Talk • Edits • Help! 12:54, 13 September 2017 (UTC)[reply]

    Filter 812 didn't disallow edits

    Hatebread (contribs) (a non-autoconfirmed user) made 5 edits, each increased page sizes by 2.7 million bytes, and for some reason filter 812 didn't disallow any of them. Is there any reason why? Do filters sometimes miss edits? —MRD2014 Talk • Edits • Help! 00:37, 14 September 2017 (UTC)[reply]

    If I had to guess, it was because the edit was commented out? Other than that, I have no idea. Seems to be working properly everywhere else. Primefac (talk) 00:48, 14 September 2017 (UTC)[reply]
    It's enabled and hasn't been changed since December 2016. —MRD2014 Talk • Edits • Help! 01:18, 14 September 2017 (UTC)[reply]
    Sorry, I meant that the edits themselves were inside of comments. My second comment was regarding the fact that the filter was tripped 2-3 days ago, and about once a week since it was implemented. In other words, "it's working, and this is my only theory why it missed these edits". Though I do notice that they were all "new section" edits - maybe that threw it off? Primefac (talk) 01:22, 14 September 2017 (UTC)[reply]
    According to the filter, it doesn't matter what the edit summary says. —MRD2014 Talk • Edits • Help! 02:42, 14 September 2017 (UTC)[reply]
    Another major AbuseFilter bug...??? It should definitely 100% have stopped this, and indeed I can test the filter against that user at Special:AbuseFilter/test and it matches. I think there was some breaking change that happened a while back, because we've had several filters malfunction, where apparently the variables being read have the wrong values, are for the wrong edits, other weirdness. I'll create a task and propose rolling back the extension to a stable version MusikAnimal talk 16:30, 14 September 2017 (UTC)[reply]
    Created phab:T175933 MusikAnimal talk 17:04, 14 September 2017 (UTC)[reply]
    Bit off topic suggession. I suppose a specific warning message that has links about copyright issue, referencing and encyclopedic writing style to this filter may benefit users who are unaware off copyright issues.
    Mahitgar (talk) 12:21, 1 October 2017 (UTC)[reply]

    Move Special:AbuseFilter/879 to disallow, or tag?

    No false positives since the filter was refined late on September 11. I don't actually understand why this is happening, but it looks like none are good edits. MusikAnimal talk 17:34, 14 September 2017 (UTC)[reply]

    @Zzuuzz: Just now noticing your comment above. What confuses me is the tripped edits don't seem to make any change beyond HTML-encoding those characters, and they're always from the mobile interface. I'll admit I am also confused as to what "proxy" means in this case. Also, I lied, there is a false positive here :( We might could use rcount to make sure the before/after are the same MusikAnimal talk 18:01, 14 September 2017 (UTC)[reply]
    I'll be honest I don't know exactly what's happening, but I do know we needed to be at least logging it. It did occur to me that it might be a Wikipedia bug, and nearly got around to asking you if CU could help fill in some of the details with the user agent. This doesn't look like deliberate changes - it could be that other changes are being discarded, but here's two interesting edits (possible vandalism or possible browser bug?). There are two distinct mobile networks which repeatedly appear and I don't think that is a coincidence: roughly 197.156/15 and 42.110/15 and I'm sure I've also seen non-mobile interface edits, but that one's probably still on a mobile, per whois. Mobile networks are far more likely to be doing caching or something, but it could be being broken even before that. It's the type of behaviour I expect from a bad PHP proxy. I'm not sure where to head next with the filter - it still looks a bit to liable for me, and I think we'll need in particular to figure out encoding in URLs. Maybe a warning? -- zzuuzz (talk) 18:47, 14 September 2017 (UTC)[reply]
    There is a consistency with the UA come to find out... A browser bug sounds more likely, from what I can tell MusikAnimal talk 19:44, 14 September 2017 (UTC)[reply]
    Thanks, that sounds about right. Perhaps I should rename the filter. So I think tagging would be pointless, and disallowing would be a bit harsh at this stage, but that warning should be able to filter out any accidental edits and we'll see what happens? -- zzuuzz (talk) 20:11, 14 September 2017 (UTC)[reply]
    I've renamed the filter and set it to warn for the time being, and we'll see what happens eh. -- zzuuzz (talk) 06:30, 16 September 2017 (UTC)[reply]

    We built some graphs to monitor Edit filter performance

    Hello everyone! As part of our research into improving Edit filter the WMF's Anti-Harassment Tools team has implemented performance tracking to monitor how fast (or slow) the feature is operating. The graphs can be found at https://grafana.wikimedia.org/dashboard/db/mediawiki-abusefilter-profiling. The graph on the left shows the 75th and 99th percentile of runtime, and the other shows the total filters and total conditions run.

    Over the next week we'll be adding in some additional reporting for sub-optimal filters. This work can be tracked on Phabricator at T174205.

    We're hoping to use this new measuring to make some decisions on how we can make AbuseFilter more performant or if we can raise the condition limit. — Trevor Bolliger, WMF Product Manager 🗨 23:46, 14 September 2017 (UTC)[reply]

    Looks good, especially the conditions/limits one! — xaosflux Talk 12:03, 16 September 2017 (UTC)[reply]

    The autoconfirmed article creation trial has begun. Filter 98 (Creating very short new article) only triggers when a non-autoconfirmed user creates an article less than 150 bytes in size. Now that ACTRIAL has begun, all articles will be created by autoconfirmed users and this filter will not trigger for the duration of the trial (trial ends March 2018). —MRD2014 Talk • Edits • Help! 01:34, 15 September 2017 (UTC)[reply]

    There are a bunch of similar filters. Should we just disable them all, or maybe change them to target non-extended confirmed users? Or users with less than say, 50 edits? MusikAnimal talk 04:03, 15 September 2017 (UTC)[reply]
    See T175225 for a phabricator task about a related issue with the page curation filters. We're keeping the old AC filter for now and simply adding the "learner" filter additionally there. I think in this case it would make sense to simply up the definition of new user to be non-extended confirmed. TonyBallioni (talk) 05:52, 15 September 2017 (UTC)[reply]
    I've updated 98 to target extended confirmed. The only other filter I could find directly affected by ACTRIAL was Page creation throttle for new users. This one actually disallows if they attempt to create more than 2 pages in a 90-second period. My guess is we don't want this for non-extended confirmed users, as there would seemingly be some legitimate use cases? Maybe target users with less than say, 20 edits? MusikAnimal talk 03:35, 19 September 2017 (UTC)[reply]

    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.


    DatBot (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
    DatGuy (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
    Ends at: 14:25, 21 September 2017 (UTC)

    (I believe this is how a request was meant to be. PS to do the 'ends at' thing use {{subst:#time: H:i, j F Y "(UTC)"|+7 days}}

    I'd like to get this flag for my bot so it could use the API to report users. Currently, the bot has to use the database, which frequently lags, thus producing stale reports.

    — Preceding unsigned comment added by DatGuy (talkcontribs)
    @DatGuy: This access group doesn't give any access to "report users" - do you mean to "report on" users? Can you provide a link to your existing BRFA? — xaosflux Talk 21:55, 18 September 2017 (UTC)[reply]
    @Xaosflux: Sure, here it is. This is the part of the code that isn't very effective: "SELECT SQL_NO_CACHE afl_id, afl_action, afl_namespace, afl_title, afl_user_text, afl_timestamp, afl_filter FROM abuse_filter_log". It basically tries to get into about the attempted edit. If the bot had access to the API, I wouldn't have to force it to use the SQL database, which has replication lag. Dat GuyTalkContribs 22:00, 18 September 2017 (UTC)[reply]
    I'm fine with the bot access from a technical level. — xaosflux Talk 22:08, 18 September 2017 (UTC)[reply]
    Note from a practical level, DatGuy does not have this access today so this request should focus on if he qualifies himself. — xaosflux Talk 22:08, 18 September 2017 (UTC)[reply]
    I have zero problem with both DatGuy and DatBot getting EFH. Would actually help some aspects of the bot's performance significantly. Ks0stm (TCGE) 22:11, 18 September 2017 (UTC)[reply]
    • That is completely up to you, my point is that as you have control of the bot credential you will effectively have the access anyway and as bots are extensions of their operators the general review of meeting criteria should be of the operator (for operators that don't already have access). — xaosflux Talk 11:28, 19 September 2017 (UTC)[reply]
    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.

    Filter 869 - "Users adding tabloid journalism to BLPs" - move from "log" to "disallow"

    This filter traps web citations to The Sun, the Daily Mail and the Daily Star on any BLPs. It's been logging for the past couple of weeks, and I think it's time we turned it on to "disallow". There are a couple of diffs I want to query - for example, this diff by Midnightblueowl which is actually talking about the Daily Mail might be argued as a false positive, though I would say per WP:BLPSOURCES that if the information is that noteworthy, the broadsheets would have picked it up. (eg: See Enemies of the People which is entirely about a Daily Mail headline without containing a single source to it). As an alternative, we could set it to disallow on just the Sun and the Daily Star, which seem to be far less contentious than the Mail, which seems to trip up the lion's share of the filter logs. Your thoughts, please. Ritchie333 (talk) (cont) 15:55, 21 September 2017 (UTC)[reply]

    I'd say disallow is far more problematic than warning, and it doesn't get my support. Plus, the RfC was very narrow and doesn't support a total ban on the other tabloids. -- zzuuzz (talk) 17:10, 21 September 2017 (UTC)[reply]
    The RFC also noted that there were situations where the Mail could be cited (e.g. in articles where it is the subject, and in older stories from before it went downhill quality wise). I don't support disallow. Thryduulf (talk) 00:39, 22 September 2017 (UTC)[reply]
    I think changing it to warn might be a better option than to disallow. —MRD2014 Talk • Edits • Help! 12:19, 22 September 2017 (UTC)[reply]
    I'd prefer disallow, but I'd go with warn as well. At least any editor adding the material cannot then complain when it is reverted, as they've already been warned not to add it. Black Kite (talk) 12:31, 22 September 2017 (UTC)[reply]
    Such links shouldn't be added in most circumstances, but there are exceptions so if it does go to warn (which I'm happy with) the wording should reflect that. Thryduulf (talk) 23:48, 22 September 2017 (UTC)[reply]

    As Ritchie mentions, I added a citation from the Daily Mail in this instance as part of a sentence openly discussing that very Daily Mail article itself (which is discussed by other Reliable Sources). I'll bow to whatever the general consensus is on this one, but I personally don't think that there are any problems in having the citation in this particular instance. Midnightblueowl (talk) 19:27, 22 September 2017 (UTC)[reply]

    A potential issue with any disallow on such things is a WP:ABOUTSELF and WP:PRIMARY conflict, especially when the site is a news source (even if a low-quality one). They remain legit sources for direct quotations, even if they're worthless as secondary sources for WP:AEIS material.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:57, 23 September 2017 (UTC)[reply]

    Request for edit filter manager bit

    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.


    SMcCandlish (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
    Ends at: 17:41, 30 September 2017 (UTC)[reply]

    Professional coder and sysadmin, been here 10 years, 100K+ edits. TemplateEditor (I'm one of the more active non-admins who answers {{edit template-protected}} requests, and often go out of my way to implement and sandbox what's requested if the requester doesn't have the skills to do the testing personally). I do not presently run any bots.

    Would like to create some informational/tracking edit filters (frequently misused templates, Web sources that are questionably reliable, and a few other cases), for editors to use as cleanup/verification tools. I have no interest in making filters that trigger actions like preventing the edit or delivering a warning (that seems more like an admin-level role to me).
     — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:22, 23 September 2017 (UTC)[reply]

    It sounds like you'll want to be asking for the edit filter manager bit instead. If that's the case could you first of all mention any experience with edit filters and perhaps regex. I've got to also say one thing we're constantly battling against is an explosion in the number of filters and associated runtime, so an application expressing an interest in creating lots of tracking filters, which in my experience not many people consistently look at, may not seem an obvious way to go. But could you give an example of such a filter, including perhaps its expression? -- zzuuzz (talk) 17:35, 23 September 2017 (UTC)[reply]
    Ah, I see, yes I mean the bit for editing them, then (I don't actually care about hidden ones. :-). Changed the heading. Don't want to create lots, and I'd be perfectly happy adding to some rather than adding new ones. As a sysadmin, I work with regex in multiple flavors all the time. Am versed in sandboxing, and of course read WP:Edit filter#Recommended uses and its material on not implementing a filter that actually does anything without first observing that it triggers exactly as expected. I've not directly worked on the edit filters here, lacking the bit to do so. Just think I can be of use; I'm one of the more tech-oriented sorts who's active most of the time. PS: I have a long reputation as an outright nay-sayer when it comes to poorly-thought-out changes to important templates, WP:P&G material, interface pages, processes, and other things that could have wide-ranging side effects; I think that's a plus in this context.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:41, 23 September 2017 (UTC)[reply]
    Thank you for answering most of the question. You know people here can be quite fussy so I'm just trying to elicit the relevant things. We can't expect anyone to know everything, but I'm sensing an element of unfamiliarity with the topic. You're welcome to persuade me otherwise. Personally I don't particularly doubt your technical abilities - what you consider a plus I consider a lack of negatives - but what I'd really like to hear about is what you intend to do. Have you considered having a go at WP:EFR or EFFP? -- zzuuzz (talk) 18:05, 23 September 2017 (UTC)[reply]
    I had not looked into EFR or EFFP; can do so. I'm more volunteering to assist than coming in with an agenda.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:45, 24 September 2017 (UTC)[reply]
    What I intend to do is draft and test some low-key edit filters mostly related to questionable sourcing, and to help fulfill requests for new EFs that are requested and not rejected (i.e. perform TemplateEditor-like work, just also with regard to EFs).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:30, 24 September 2017 (UTC)[reply]
    • Q: Can you give an example of a filter you might create and how you would code it? CrowCaw 18:03, 23 September 2017 (UTC)[reply]
      Two examples that come to mind are citations to QuickAndDirtyTips.com/grammar-girl and MessyBeast.com. Both of these are personal blogs by people with some credentials in a tangentially related field, but not expertise in the one central to what they're writing about (the author of the "Grammar Girl" material at the first is not a linguist but a journalism professor (i.e., steeped in one very particular form of writing, which has numerous norms that conflict sharply with other writing styles and registers of English), and the author of the latter is not a zoologist (or veterinarian, ethologist, etc., much less a felinologist). The sites have huge followings, and are frequently cited on the web as "authorities", but do not make their own sourcing clear, and are mostly advice columns (primary source material) and collections of factoids from other places (tertiary material). They can be legitimately cited here as primary sources for certain things when this is done properly, but more often people try to cite them as secondary. We have very few watchers on the sorts of pages where citations to these websites are most likely to appear. Haven't had coffee yet (it's 5:40-something a.m. where I am), but I can produce a sample filter later. I'll look first into the EFR and EFFP recommendation above. I'm not here to collect some headwear but to be of use.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:45, 24 September 2017 (UTC) PS: Looking at the QuickAndDirtyTips.com site again for the first time in ages, I note that it's ballooned to way more than the Grammar Girl material and how has multiple columnists writing on fitness, business, psychology, etc., making it more likely to be used as an probably-bad source on more pages, like the old About.com.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:30, 24 September 2017 (UTC)[reply]
    • Looks good for a tag-only, though as you implied there's some tuning to streamline it (such as one keyword that will catch all case variations). You may want to read [4], there's some serious power in this tool. :-) CrowCaw 17:12, 24 September 2017 (UTC)[reply]
    • Just on the technicalities of the filter - and I won't particularly hold this against SMcCandlish as he doesn't have proper access to the filter testing tools - it seems to be confusing plain text searches (contains | contains_any), with regex (which uses the pipe (|) character). Compare the use of irlike in 657 which is referenced with perhaps 31. It also seems to be lacking enough parentheses, and is testing for (Namespace == 0 AND link1 OR link2). Compare 869 and see the archive. -- zzuuzz (talk) 18:35, 24 September 2017 (UTC)[reply]
    • Additionally you didn't escape the . in the URL, which is needed since it is a valid regex character. I'll note this involves an understanding of regex in general, not a familiarity of the extension, though you might have discovered your mistake using the debugging tools MusikAnimal talk 14:50, 27 September 2017 (UTC)[reply]
    • Lack of testing tools (and more detailed documentation – though I'll go check out that mediawiki.org page) is a bit of a hamper. Deets:
      I was avoiding irlike on purpose, because the docs say regexes are expensive for edit filters; the implication appeared to be that contains will match literal strings not regexes. That keyword is essentially undocumented, but the contains_any says it works with strings. I noted that filter 126 didn't escape the . in youtube.com. It wasn't clear that the pipe wouldn't work without irlike or rlike. The pipe is used as an OR more generally in the syntax in other ways, so it didn't seem confined to regex parsing. I had my doubts about "foo|bar", and suspected "foo"|"bar" might be required.
      Anyway, I'm not sure if it's better to just use irlike, or try to catch case variations another way. That's a "what we've learned about filter efficiency" question for you all. :-)
      On parens, yes, the intent was (Namespace == 0 AND (link1 OR link2)); methinks this is the fix.
       — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:18, 29 September 2017 (UTC)[reply]
    • Q: I know it's been a while (7 years), but your last RfA had a lot of opposition. Do you think you have overcome the issues that led to that opposition, if so how? — xaosflux Talk 23:12, 23 September 2017 (UTC)[reply]
      Oh, geeze that's from an embarrassing time. At my first RFA I was an enthusiastic noob, and at the second I'd been taking excessively bureaucratic and argumentative stances that were more about trying to make WP operate the way I thought it should rather than vice versa. I've done a 180 on that stuff. These days I'm a huge fan of the WP:POLICY / WP:LAWYER principle that WP's rules and processes are to be interpreted in the spirit in which they're intended not their exact letter, and that they're here to serve our needs and to codify our best practices, not change them. At any rate, I have no interest in an RfA no. 3; the "enforcement" aspects of adminship are of zero interest to me; instead, I've been highly supportive of tech-work unbundlings like template editor and page mover (and would have commented favorably in the unbundling RfC atop this page if I'd not been busy off-site at the time). Happy to address any more specific concerns, but this may all be moot if I need to be shunted into EFR and EFFP for a long while before being considered for EFM.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  12:45, 24 September 2017 (UTC)[reply]
      Thank you for the reply, like I led with it has been a long time. I don't know about "a long while" but I would like to see activity at EFR/EFFP for this access. Creating any deny filter is in effect "enforcement" of something as well. — xaosflux Talk 17:23, 24 September 2017 (UTC)[reply]
      Sure. I didn't have any interest in deny filters, just logging ones.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:18, 29 September 2017 (UTC)[reply]

    Endorsements / Comments

    • Oppose at this time, however I encourage EFR/EFFP engagement as a way to enter this arena. — xaosflux Talk 15:38, 27 September 2017 (UTC)[reply]
    • Oppose also at this time. I'd like to see more familiarity with the edit filter before granting the bit. I'd encourage more reading of the existing filters, the documentation, and have some input to practise (and demonstrate) putting it all together. -- zzuuzz (talk) 18:21, 27 September 2017 (UTC)[reply]
    • Request change: EFH rather than EFM might be helpful; it provides a lot more access to pre-existing filter code, which honestly seems like better documentation. :-) A large number of the filters I attempted to examine were not available to me. E.g., I can't look at 31, which zzuuzz suggested looking at.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:18, 29 September 2017 (UTC)[reply]
    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.

    EFH bit request

    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.


    Requesting EFH bit to view hidden logs. I do a lot of work at COIN leading discussions about conflicts of interest. I expect this right would help me discover relevant COI/UPE cases as well as general vandalism etc. I understand the BEANS need for discretion. If it matters I have academic training in regexp and have demonstrated their use here. ☆ Bri (talk) 16:03, 27 September 2017 (UTC)[reply]

     Donexaosflux Talk 01:51, 1 October 2017 (UTC)[reply]
    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.

    I asked about this above and got no reply. Since this filter currently doesn't do anything, I've disabled it. I think it might be useful to have it check for an edit count less than say, 50, but I'm not sure about the disallow action MusikAnimal talk 20:03, 27 September 2017 (UTC)[reply]

    an invitation to Edit filter managers

    Hi,

    This is an invitation to Edit filter managers and patrollers who refer to edit filters from your wiki project to share and know about effective public filters from various wikimedia wiki projects.

    It is almost eight years since March 2009, that Edit filters are in use on various Wikimedia wiki projects. At meta we have started a platform page m:Edit filters benefiting to various local Wikiprojects to know good and effective (public) edit filters by sharing of relevant information with rest of wikimedia community. This will help editfilter managers, and there by concerned projects, to benefit from maximising potential of best possible (public) edit filters.

    We are keen to have your participation in this collaborative and constructive endeavour and the discussions.

    Mahitgar (talk) 11:09, 30 September 2017 (UTC)[reply]

    EFH bit request for Mahitgar

    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.


    Requesting EFH bit to view hidden logs. My interest is more of academic nature to study and help improve m:Edit filters benefiting to various local Wikiprojects this meta page started by me. It will also help in giving references to my bugs filed at phab.

    I am not technical expert on regex but have learned, compared and implemented techniques from en:wp and other lang wps past four-five years public filters here. While I have tried inter acting on en wp ef forums, frankly many times may be due to lack of man power, its slow in responding. Over the years I have been supporting mainly help pages on my local lang wiki. I suppose my participation may help, help pages and and once in a while in en wp ef related support/ help activities.

    Whatever you decide but please keep supporting. m:Edit filters benefiting to various local Wikiprojects

    Thanks and regards

    Mahitgar (talk) 08:19, 1 October 2017 (UTC)[reply]

    • Oppose I'm not sure how viewing the hidden logs will help with the page you've set up. Almost all private filters pertain to specific vandals here on English Wikipedia. They likely will not be of as much use elsewhere, and moreover they should not be published on any public page like the one you speak of.
      I would also recommend renaming your page to something like "Edit filters of cross-wiki interest". The term "Wikiproject" can be confused with Wikipedia:WikiProject, which is different than a project like enwiki, frwiki, etc., also known simply as a wiki. Other wikis also use the term "WikiProject" to refer to their own internal, specialized collaboration groups. MusikAnimal talk 14:32, 2 October 2017 (UTC)[reply]
    • Oppose per MA. ~ Rob13Talk 15:23, 2 October 2017 (UTC)[reply]
    • Oppose per above concerns. I'd like to see a bit more local activity before this was handed out, as was decided in the perm's RfC -- There'sNoTime (to explain) 15:37, 2 October 2017 (UTC)[reply]
    • Strong Oppose--I want to see much more local activities related to specific usage of EFs before granting the right.Winged Blades of GodricOn leave 16:18, 2 October 2017 (UTC)[reply]
    Comment: Thanks, As per MA's good suggession I will go for change of page name. In most cases specific words which want to get filtered are confidential and not all technical configurations. If not all atleast few stable configurations are shared (sans confidential part/wors) on common meta page all wikis will benefit from experience and help improve efficiancy to all of us.
    As I said my interest in EFH bit is limited only and not granting as of now is not an issue to me. Just I wanted to bring a common page into focus, and that has been achieved by this discussion. Thanks for considerations. It is ok to close the discussion as EFH bit not accepted.
    Mahitgar (talk) 05:00, 3 October 2017 (UTC)[reply]
    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.

    Suggested filter

    Just a heads up, but I sent an email to the editfilter list email with a suggestion to expand the filters to stop a recent type of spam. I emailed it in order to not give any ideas to possible vandals. Thank you. Nihlus 01:52, 3 October 2017 (UTC)[reply]

    checkY Responded to by MA -- There'sNoTime (to explain) 20:52, 4 October 2017 (UTC)[reply]

    Request for Edit Filter Helper - Dane

    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.


    Dane (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

    Hello,

    I am requesting the Edit Filter Helper right so I can view hidden logs. I am a Tool Administrator at the ACC tool and run across tripped filters occasionally that I am unable to view/evaluate in the course of my work there currently and this would help me in processing those requests. Thank you! -- Dane talk 03:50, 4 October 2017 (UTC)[reply]

    A: Yesterday, I worked a request for example that showed an Edit Filter was tripped but only had a number specified. When we defer requests for CheckUser, we've been asked by CU to supply as much information as possible to assist in their processing of the requests. Because I did not have that information available I wasn't able to properly defer even as a tool administrator and I had to find an on-wiki administrator to research the specific request and write up the summary for CU which can add a delay in processing. In some cases, having the EFH right may even allow a bypass for CU if it's clear that it's the target for a filter created for specific LTAs. -- Dane talk 19:43, 4 October 2017 (UTC)[reply]
    Expanding on the above, I don't believe being an ACC tool administrator is a sufficient reason to grant, and given the fact you were able to find an administrator to assist there's no real issue.. However, do you posses sufficient understanding of regex/AbuseFilter syntax to be able to reliably make the call on if a specific LTA filter was indeed targetting the request IP you're looking at? -- There'sNoTime (to explain) 19:47, 4 October 2017 (UTC)[reply]
    It is true that I was in one instance able to find an administrator who holds sysop on en-wiki as well to evaluate it, however there have been times where there is a delay in that. In asking for the right i'm looking to be able to avoid this delay to resolve the issue myself. I do have a basic understanding of regex and I would defer any case that was in question or unclear to me per the existing operating guidelines. I do not have intent on authoring any filters now or in the future. -- Dane talk 20:20, 4 October 2017 (UTC)[reply]
    • Oppose No real on-wiki need for the tool if other, more trusted editors administrators and EFMs are easily available via the mailing list or on IRC. There's a reason we have private filters and granting access solely for off-wiki tools is not a good precedent to set, given there is a real risk of sharing details of private filters with unauthorised parties on mailing lists we would not have access to. EFH was not created for this purpose -- There'sNoTime (to explain) 20:59, 4 October 2017 (UTC)[reply]
    This was the wrong place to bring up my concerns about criteria #1 -- There'sNoTime (to explain) 08:47, 5 October 2017 (UTC)[reply]
      • Commenting in my capacity as one of the ACC project leads, this seems like an odd objection to make against a group of users who are specifically vetted for their ability to comply with privacy restrictions and are indeed required to sign the Access to nonpublic information policy. --FastLizard4 (talkcontribs) 22:08, 4 October 2017 (UTC)[reply]
        • The signing of that document doesn't come into it - I've signed multiple NDAs for WMF, but they don't make me more or less suitable for access. The reason for my objection is as I detailed above - there's no need for this right to be granted -- There'sNoTime (to explain) 07:05, 5 October 2017 (UTC)[reply]
          • Your own argument is "No real on-wiki need if other, more trusted editors are easily available". With all due respect, if your argument for suitability for access doesn't involve user trust, then why did you literally put those words in your argument? --FastLizard4 (talkcontribs) 07:33, 5 October 2017 (UTC)[reply]
          ...Expanding on my above comment, @There'sNoTime:, your argument can be easily rephrased from "No real on-wiki need for the tool if other, more trusted editors are easily available" to "No real on-wiki need for the tool since Dane is not as trusted as other editors." I believe that it is fair to ask you to expand on the reasons for this distrust in response to my original comment that it seems odd to object on a trust basis to one of the more vetted and trusted groups on Wikipedia, or that you use another basis for your argument that there is no demonstrated need here. --FastLizard4 (talkcontribs) 07:43, 5 October 2017 (UTC)[reply]
          Rephrased perhaps, but that was not the intended meaning - it's clear Dane is a trusted individual as he's been accepted to the lofty position of a tool administrator, but he's not a "trusted editor" in way of advanced permission. I use the phrase "trusted editors are easily available" to refer to the enwp admins who are active at ACC (not counting the many many active admins on IRC). As Crow rightly points out below it seems like an email with the regex would cover 99% of the issues and I'll add a !admin can you help me with filter X in #wikipedia-en connect would solve the rest. You explain below you have an outsider perspective with respect to edit filters, so perhaps you're not familiar with the days people have sunk into creating and maintaining our LTA filters? -- There'sNoTime (to explain) 08:06, 5 October 2017 (UTC)[reply]
    Rephrased the above for clarity, additions in green -- There'sNoTime (to explain) 08:19, 5 October 2017 (UTC)[reply]
    @There'sNoTime: Again though, I don't feel like you're addressing my argument - my argument is that you have no reason to consider Dane untrusted, yet you continue to make your case as if that's a given (you state "he's not a 'trusted editor' in way of advanced permission"). I would like you to expand on the specifics for why you are arguing this or abandon the premise. Also, though I appreciate the labor that goes into writing effective filters, I don't see how stating that fact has any bearing on Dane's request - unless of course we take as a given that Dane is untrusted and is thus a risk for undoing all that work, which is the point I am contesting here. --FastLizard4 (talkcontribs) 08:17, 5 October 2017 (UTC)[reply]
    Outsider perspective here too. I don't have a strong opinion on this, but I was wondering, this is a new user group, I am getting an impression that this is being vetted as if it were a WP:EFM request rather than EFH? Just a thought. Alex ShihTalk 08:24, 5 October 2017 (UTC)[reply]
    This isn't a hill I want to die on, but my point is being misunderstood. Dane is perfectly trusted, I think he should have passed RfA and that isn't the issue I have. Granting criteria #1 highlights a requirement for "need". I don't see a need here when other trusted editors (read "Administrators, EFMs" as I clarified above - that was my poor wording) are available on IRC and through a mailing list. Perhaps I am using this as a point to highlight the inadequate definition of "need" (the major concerns from the RfC were creep), and that's not fair on Dane, so I apologise there. Consider my oppose struck, but a discussion needs to happen over things like this. This was the wrong place to have that discussion -- There'sNoTime (to explain) 08:41, 5 October 2017 (UTC)[reply]
    @There'sNoTime: Okay, I see the point you're making now. After our discussion on IRC, I can see the question of need itself being valid even when trust is disregarded, but that's an area where I'm thoroughly unqualified to comment, so I'll leave it to others to decide. --FastLizard4 (talkcontribs) 08:54, 5 October 2017 (UTC)[reply]
    • I'm still not sure that ACC yields enough of an ongoing need for the access. The logs won't tell you why a filter was tripped, just that it was... you'd need to dig into the regex to determine why. And since the number of EFs dealing with ACC is small compared to the total (Meta prefers to handle name blocks now), it seems like an email with the regex would cover 99% of the issues, with that 1% being new additions to the filter. CrowCaw 22:33, 4 October 2017 (UTC)[reply]
    • @Crow: I think this argument can be reversed and be equally as valid - even if there isn't a hard ongoing need, if there aren't any specific issues that lead to the candidate user to be considered untrusted despite their long-time status on Wikipedia, as long as they are competent in regular expressions and know not to break things, and as long as there are even potential gains to be had, is there harm in granting the user group? To me, the potential usefulness of this access is at least some kind of positive factor, and there don't seem to be any negative factors beyond lack of precedent which seems like should it should be a relatively minor factor - though this is admittedly very much an outsider perspective (with respect to edit filters). --FastLizard4 (talkcontribs) 07:51, 5 October 2017 (UTC)[reply]
    • Support - this is a perfectly reasonable request IMO. This is such an inconsequential right that I can't imagine why we would turn away anyone with a potential use for it. -- Ajraddatz (talk) 00:19, 5 October 2017 (UTC)[reply]
      • As for this being an inconsequential right, I draw your attention to the closing caveats, namely community and/or the granting administrator are adviced to carefully evaluate the candidates before granting the flag due to the huge fallouts of any misuse. -- There'sNoTime (to explain) 07:23, 5 October 2017 (UTC)[reply]
        • There is almost no fallout for misuse. The absolute worst-case scenario is that an LTA is able to figure out what the filter conditions are, so they can bypass it a few minutes earlier than they could by trial and error. And when any sort of trusted editor is the one requesting the right, we can be pretty sure that the worst-case scenario won't happen. -- Ajraddatz (talk) 08:31, 5 October 2017 (UTC)[reply]
    • Support - Per Ajraddatz. Perhaps the demonstrated need (#1) is not strong enough, but I would be satisfied if there are potential uses (indicated in the response above) by a trusted editor. Alex ShihTalk 06:44, 5 October 2017 (UTC)[reply]
    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.