Wikipedia talk:Edit filter

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:EF)
Jump to: navigation, search
the Wikipedia Help Project (Rated Project-class, Mid-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
 Project  This page does not require a rating on the project's quality scale.
 Mid  This page has been rated as Mid-importance on the project's importance scale.
 

What should the criteria for use of the block function be?[edit]

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

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

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

Two edit filter RfCs[edit]

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

Removing EFM rights for those desysoped under a cloud[edit]

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

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

Support[edit]

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

Oppose[edit]

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

Comments[edit]

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

Looking to help[edit]

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

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

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

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

Citebomb?[edit]

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

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

Recent changes to guideline[edit]

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