An admin of Wikipedia pointed out that global filters should be disablable locally, likely by those on the wiki with abusefilter-modify (or a split-off permission). This would allow a local community to avoid false positives without having to bother those trusted to modify global filters (stewards).
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T54056 Uninstall UploadBlacklist extension from Wikimedia wikis | |||
| Resolved | Urbanecm | T46975 Deployment of global AbuseFilter rules | |||
| Open | Feature | None | T45761 Allow local disabling of global AbuseFilters |
I think this is something that is a good idea (similar to how you can override the global spam blacklist with a local whitelist).
Currently $wgAbuseFilterDisallowGlobalLocalBlocks only handles blocks and will stop all filters, rather than individual ones.
I'm not sure how you would go about implementing this though, should another column be added to database for which wikis have disabled it?
It would probably need to be done like SpamBlacklist's whitelist-- each wiki would keep a list of global rules it would ignore in their DB.
Like SpamBlacklist, the local wiki pulls in the global AbuseFilter rules, and then processes them. So to check against a local list of whitelisted rules wouldn't be too inefficient.
(In reply to comment #2)
It would probably need to be done like SpamBlacklist's whitelist-- each wiki
would keep a list of global rules it would ignore in their DB.Like SpamBlacklist, the local wiki pulls in the global AbuseFilter rules, and
then processes them. So to check against a local list of whitelisted rules
wouldn't be too inefficient.
I think the most convenient solution would be to implement a new sub page of Special:AbuseFilter where global filters can be (locally) disabled/ enabled. While the application code for this would be pretty easy to write it certainly would need DB schema changes.
It would be more worthwhile getting spam filters fixed/updated so we don't have these issues, especially if we have the situation that wikis are getting multiple false positives. I like the idea mentioned elsewhere in Phabricator about talk pages for spam filters to make it easier to report issues. I watch global filters and look to update them on the first occasion that a problem is noticed, so where we have a case of multiple situations seems unusual.
Noting that it is now possible for global filters to be easily coded to limit/omit based on language or sister type, so omitting certain wikis is relatively easy
No, but local communities can request that a global filter be disabled (eg at https://meta.wikimedia.org/wiki/Meta:Requests_for_help_from_a_sysop_or_bureaucrat) if there is local consensus to do so. Its fairly simple, just add
& (wiki_name != "example")
with "example" being replaced by whichever wiki wants the filter disabled.
Having to maintain a list of every project name inside a global filter configuration that doesn't want that global filter on their local project seems like a bad design. Having the local project have a whitelist of GAF ID's puts the control in their hands.
This could be another use-case for T323811: [EPIC] Community configuration 2.0: Factor Community configuration out of GrowthExperiments (unless we want to keep things hidden from the public).
Community configuration may allow local community to have more fine-grained control of global abusefilter. Other than locally disabling, some other options are possible, such as:
In a nutshell: there may be options for local community to control (1) whether to enable a global filter and (2) specific action of the filter.