The following request for comments is closed. There is a clear consensus to pass this proposal. Some of the concerns presented are valid, such as applications on larger wikis. However, I find the concerns presented are mitigated by the proposal itself: a mechanism by which to opt-out. Operator873 connect 21:59, 5 July 2023 (UTC)
Background and rationale
On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the Wikimedia Stewards. Global filters are a powerful tool that is used to fight against long-term abusers (LTA) that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, global/local blocks are significantly limited).
All Wikimedia projects classified[note 1] as small or medium are already subscribed to global abuse filters by default (some large projects decided to opt in as well, including Wikidata).
Sometimes, a long-term abuser happens to know about projects where global filters do not work, and intentionally abuse those projects. Often, LTAs decide to vandalize those projects classified as large where there is little to zero active editing community. This is possible, because projects are classified as large purely based on the number of articles (community size is not factored in that classification).
Whenever that happens, it is difficult to continue the countervandalism work for the Stewards, as the global abuse filters they configured do not work on those projects. Occasionally, this results in emergency steward actions (recent example) and creation of local filters that duplicate the already-existing global filters.
This proposal aims to make global countervandalism more effective by enabling global abuse filters as opt-out feature on all public Wikimedia sites. This change will only affect large projects that are not yet subscribed to global abuse filters (list of those projects is available below).
- ↑ Classification of Wikimedia projects as small/medium/large is done by system administrators mostly for performance reasons, and it is based on the number of articles each projects has (community size is not considered by this classification). List of projects by their classification: small, medium, large.
Make subscribing to global abuse filters opt out on all large wikis. This will result in enabling global abuse filters on the following sites:
|List of projects where global abuse filters would be enabled
Note: This proposal only affects wikis classified as "large". All other Wikimedia projects are already subscribed to global abuse filters, and this proposal will not affect them.
List of projects wishing to opt-out
If a community decides to opt-out themselves from global abuse filters before this RfC is closed, please list it here (including a link to a local discussion).
--Martin Urbanec (talk) 17:14, 12 March 2023 (UTC)
- Support as proposer. I've also sent a massmessage informing about this proposal. --Martin Urbanec (talk) 17:14, 12 March 2023 (UTC)
- Support As proposer, no concerns. – Tryvix t 17:25, 12 March 2023 (UTC)
- Support As proposer. Đơn giản là tôi (talk) 17:52, 12 March 2023 (UTC)
- Support But, is there a need for a local "Abuse-filter" group for large project sysop on the Meta-wiki? One of the reasons that large wikis did not need global filters was because there were enough sysops who could respond immediately to abuses and set up filters. Subscribing to a global filter may cause malfunctions due to differences in languages and projects. However, I do agree with the request text. So, a trusted person should be able to fix malfunctions or opt-out of the filter. Syunsyunminmin 🗨️talk 18:10, 12 March 2023 (UTC)
- Question: Will global filters be customizable per-wiki basis? If so who'll customize them? Will these filters visible to local admins/interface-editor/(users with abusefilter rights basically)? How will wiki-based detection and correction be done if global filters prevent a useful edit because of language differences? Has such an event been detected before?--anerka (talk) 18:14, 12 March 2023 (UTC)
- Hi @Anerka, thanks for the questions. First of all, I'd like to clarify that global abuse filters are an existing feature (see Global AbuseFilter); this RfC doesn't propose new features, only an expansion of an existing feature. Unfortunately, it's currently not possible to customize global abuse filters on per-wiki basis. Most global filters are visible to everyone at Special:AbuseFilter (on Meta-Wiki), except private filters, which can be only viewed by the stewards, Meta-Wiki administrators and global abuse filter helpers/maintainers. In my opinion, the abuse filter helper role (and/or limited Meta-Wiki adminship for a read/write access) can be granted to any local experienced filter maintainer who asks, to share the filtering knowledge. In general, global abuse filters maintainers are experienced filter authors, and they double-validate each filter in a log-only mode, before eventually deploying it everywhere. Hope this helps. Martin Urbanec (talk) 19:46, 12 March 2023 (UTC)
- Support It'll be helpfull. ايـوب (talk) 18:46, 12 March 2023 (UTC)
- Support--— Osama Eid (talk) 19:28, 12 March 2023 (UTC)
- Support Absolutely supporting this. It will be a huge improvement to countervandalism efforts. – Aca (talk) 19:55, 12 March 2023 (UTC)
- Support This is helpful for large-looking, small wikis like fawiki. :) Jeeputer (talk) 22:26, 12 March 2023 (UTC)
- Support Our volunteer stewards work incredibly hard to fight spam, vandalism and other violations, and anything we can do to make their job easier is to be embraced. If certain wikis (I'm looking at you, enwiki and dewiki) wish to opt out, they can still do so. This, that and the other (talk) 23:30, 12 March 2023 (UTC)
- I do want to see phab:T45761 resolved first.--GZWDer (talk) 06:36, 13 March 2023 (UTC)
- That's the point. Global abuse filters seem to be useful and wonderful, but that's not all. I hope to provide some more detailed control rights for local wiki. Oppose until which like phab:T45761 can be resolved. --Cwek (talk) 06:54, 13 March 2023 (UTC)
- Hi @GZWDer and @Cwek, disabling global filters on the local level is somewhat possible with the current setup. While local communities don't currently have direct control over global filters, it is possible to exempt a wiki from an existing global filter. For example, frwiki requested to be excluded from global filter #110, which happened. I believe Meta-Wiki admins and Stewards should always comply with a wiki's decision to opt out from a filter. Does this work as an adequate solution for now? Martin Urbanec (talk) 15:53, 14 March 2023 (UTC)
- Yeah, I know that, begging the Honourable meta-sysop to add something to exempt a wiki from an existing global filter. BUT, I think that it is not enough. I hope that it could give local wiki more choice and control on Global AbuseFilter, including allow local administrators to view the contents of private global filters, and to decide whether to enable or disable specific global filters locally. This issue is created in 2013, but it seems you have never dealt with it. --Cwek (talk) 00:37, 15 March 2023 (UTC)
- I've also asked the local some questions: how many Cross-wiki abuse will affect our site, and how many useful and general filters could apply to our site. For the former, what I have observed is rare; for the latter, some of our local filters are source code copied from other wiki, and a considerable part is designed for the language of local. I also have looked at the current enabled global filters , and quite a few are private, and only meta-sysop knows what's inside, possibly excluding some local wiki admins without the rights.
- For small and medium-sized sites, Perhaps they have fewer user, or indeed to reduce the administrative burden, they accept the offer they can't refuse. But for large-sized sites, they have more user, more management staff, or there are more complicated situations to deal with, they are so large that they could need the ablity to decide which filter they should need to. A one-size-fits-all approach does not bode well, and similar incidents have happened before. --Cwek (talk) 01:08, 15 March 2023 (UTC)
- Support A coordinated effort will be very helpful. -Mys_721tx (talk) 06:38, 13 March 2023 (UTC)
- Support. —— Eric Liu（Talk） 06:58, 13 March 2023 (UTC)
- I am afraid the filters to be tailored to English language and culture. I have two concerns about that: 1) If all filters are strictly targeted just on IPs or on newly created accounts or are just labeling, that would be probably acceptable, but I really don't like to annoy precious experienced long-term editors when they use some locally innocent word which is taboo elsewhere. How that can be prevented to happen with authors of filters not knowing all the languages and cultures? 2) I suppose there is no support for warning translation which would actually explain the user in his own language what is the problem?--Tchoř (talk) 07:58, 13 March 2023 (UTC)
- 1) There are currently 99 global filters enabled , most of them regarding vandalism/spam from IPs/newly created accounts, other filters are targeting crosswiki LTAs. As an experienced editor you should not be annoyed by any of those filters
- (note: all global filters have to be thoroughly tested to make sure there are minimal false positives for IPs/newbies as well).
- 2) Global abuse filter usually show MediaWiki:Abusefilter-warning or MediaWiki:abusefilter-disallowed (if the filters warn/disallow and not just log/tag edits without further action). These warnings are being translated via translatewiki 
- Just try it by changing your account settings to a different language and visit Special:AbuseFilter/123 or any other public global filter -> click on the blue box „Show/Hide preview of selected message“ in the „actions“-section and you will see the warning showing in all languages where global abuse filters would be enabled. Johannnes89 (talk) 15:35, 14 March 2023 (UTC)
- That message is really unhelpful; how are new users supposed to have a clue to what to do? That message must point to a link where users can report any issues they have (for Wikibooks, this would be here). Leaderboard (talk) 17:36, 14 March 2023 (UTC)
- Hi @Leaderboard, note the message respects standard customization techniques – for English Wikibooks, b:MediaWiki:Abusefilter-disallowed would be displayed. That local override can provide a link to a good place to report false positives to. Such a link's not included in the default (TWN-provided) message, because the place is different from wiki to wiki. Martin Urbanec (talk) 22:37, 14 March 2023 (UTC)
- @Martin Urbanec:, there are a couple of issues here. One is that many wikis don't know how to do that; for example. Malayalam Wikipedia's equivalent does not point to anywhere (just asks to contain an admin, but how is a new user supposed to know who that is?). Similarly, if the language is for any reason different, you'll get the generic message. In my opinion, this needs to point to (for example) a Wikidata page that can automatically forward to the right place for the user to ask. Leaderboard (talk) 05:16, 15 March 2023 (UTC)
- Looking at your example, this seems to be a problem for the current set of global abuse filter projects, as Malayalam Wikipedia has global filters enabled right now .
- Larger projects (which are affected by this RfC) usually have local customized versions of MediaWiki:Abusefilter-disallowed pointing to a local help page e.g. enwiki, eswiki, dewiki, nlwiki... Johannnes89 (talk) 09:43, 15 March 2023 (UTC)
- I looked to global filters and most of globals ones (from first 150) are secret. Have every big wiki some meta admin? How can local admin support something without knowing impact? I remember some issues with global spamlist (useful link on global blacklisted domain) and I am afraid thesre should be some issues with global abusefilters too. JAn Dudík (talk) 09:07, 13 March 2023 (UTC)
- 1) Judging by the languages of Meta admins  and Stewards, most projects which are currently not affected by global abuse filters would have someone speaking their language if there are issues.
- 2) Local admins can know about the impact by looking at the local filter log, where local & global abuse filter hits appear alongside (example ). They could support by either applying for Abuse filter helper (granting them the ability to see private global filters) or applying for (limited) adminship on Meta if they want to modify global filters. In addition local admins could always ask for private filter details via Wikimail or other non-public means of communication. Johannnes89 (talk) 15:47, 14 March 2023 (UTC)
- Support There's an opt-out option for those who do not want interference from global filters; that sounds good enough. NguoiDungKhongDinhDanh 17:26, 13 March 2023 (UTC)
- Support - De facto it's a rather small change, every community who doesn't want to be part of those can just opt out. Not to mention that many communities are starting to have AI fighting vandalism bots on top of edit filters. We shouldn't be scared of automatization. - Klein Muçi (talk) 10:13, 14 March 2023 (UTC)
- Question: I have three important questions:
- Would it be possible to selectively switch off some of the global abuse filters (in case they start to generate a lot of false positives for example)? And if yes, who will be able to do it - local admins or stewards only?
- Would it be possible for local admins/bureaucrats/checkusers to see the private global filters? Or at least would it be possible to obtain the right without having to win the steward's elections?
- And the most important question: As far as I know, there are limitations of maximum filter complexity ($wgAbuseFilterConditionLimit) and allowed total execution time, which apply to all filters together. What will happen if we add the global filters? Will they "spend" the local resources, which are already quite limited, or will they get extra time/conditions from the MediaWiki engine dedicated just for them?
- As far as I can see, there are 318 global abuse filters. If they will have to share the 1000-condition limit and the total execution time limit with our local filters - this could get very problematic... -- Q-bit array (talk) 11:57, 14 March 2023 (UTC)
- And one more question: Would it be possible to translate the messages from the global abuse filters displayed to the users, who trip the filter? Not everybody can understand English in a non-English Wikimedia project. -- Q-bit array (talk) 12:49, 14 March 2023 (UTC)
- Hello @Q-bit array, thanks for the questions. Please find my answers below:
- The set of variables fed into AbuseFilter includes
wiki_name (populated with the wiki ID, e.g. enwiki, cswiki, ruwiki, kowiki, etc.) and
wiki_language (populated with the language code). Those variables can be used to opt-out a wiki from a particular global filter. This feature is already used; for example, frwiki requested to opt out from global filter #110. Because the opt-out is set in the filter's code itself, it can only be done by someone with the ability to change the filter (Meta-Wiki administrators, stewards and global abuse filter maintainers).
- Access wouldn't be provided automatically, but it can be given on-request. Abuse filter helpers (AFH) group exists to provide read-only access to abuse filters when needed. I believe that being a filter maintainer on one project needing to see global filters is a perfect usecase for AFH. In the past, AFH was granted explicitly to provide access to private global filters (example).
- I'm not sure about the answer to that question. Maybe @Daimona Eaytoy can step in and answer it.
- Messages by global abusefilters display localized when a localized version of the message exists. Many (if not all) global abusefilters make use of the default mediawiki:Abusefilter-disallowed message for that reason. When a need for a custom filter message arises, it should be possible to offload it to WikimediaMessages extension and have it localized via Translatewiki.net. However, the filter title (if included in the message) is not localizable.
- Hope this helps! Martin Urbanec (talk) 15:49, 14 March 2023 (UTC)
- Hope the question on $wgAbuseFilterConditionLimit is answered soon. It is difficult to vote support without the answer — we obviously do not want to see local LTAs sneak through because local filters are stopped by global filters using up the condition limit and execution time limit. ネイ (talk) 15:36, 15 March 2023 (UTC)
- The total execution time is displayed in the interface, but there's no limit on it. The number of conditions used is indeed limited (to 1000, in most cases) as you pointed out, and yes, conditions from global filter would be added to conditions from local filters. I don't think that's a problem though. In fact, I'd support unconditionally increasing the condition limit to 2000 on all projects. The thing is, the condition limit sucks at measuring the performance of a filter. It's very easy to write a filter with 1000 conditions that runs super-fast, and a filter only consuming a couple condition but that is also very slow. We could raise the limit to 2000 if this RFC passes. Daimona Eaytoy (talk) 18:10, 15 March 2023 (UTC)
- Thanks for the reply, Daimona! Raising the limit to 2000 (two times what it is now) together with implementing this proposal sounds like a good idea. @Q-bit array and @ネイ, what do you think about that? Martin Urbanec (talk) 16:23, 17 March 2023 (UTC)
- Saw the announcement in Tech News; I support the condition limit change. ネイ (talk) 01:17, 28 March 2023 (UTC)
- Support — TheresNoTime (talk • they/them) 16:23, 14 March 2023 (UTC)
- Support --Snookerado (talk) 17:29, 14 March 2023 (UTC)
- Support, though I am not entirely comfortable with giving wikis global opt-out rights. In many cases I've seen global abuse filters conflict with local equivalents, which serves to only confuse people, especially for admins/patrollers there. Keeping filters global with filter-level opt-out provisions would be a better choice in my opinion. Leaderboard (talk) 17:35, 14 March 2023 (UTC)
- Support --Der-Wir-Ing ("DWI") talk 19:23, 14 March 2023 (UTC)
- Strong support No doubt for me! The fact that a single project can choose whether to opt-out or not makes the proposal more than valid! I also point out that on itwiki there are already several users who supports opting-in and activating global filters. --Superpes15 (talk) 11:48, 15 March 2023 (UTC)
- Strong support Clearly. Yes, having an easy way to locally disable a filter would be great. Yes, false positives may occur. Yes, we may have to increase the condition limit on all wikis before making this change. But I don't think any of these is a showstopper. I've heard people say "global abuse filters are not really global" WAY too many times, and it's clear that this has caused issues with LTAs in the past. An imperfect implementation would be better than the status quo. --Daimona Eaytoy (talk) 18:15, 15 March 2023 (UTC)
- Strong support --SRuizR 22:33, 15 March 2023 (UTC)
- Strong support--Àncilu (talk) 22:45, 15 March 2023 (UTC)
$wgAbuseFilterLocallyDisabledGlobalActions should be set true for the actions that are disabled by default (block, degroup, rangeblock).--SRuizR 23:23, 15 March 2023 (UTC)
- As Wikipedian from Hebrew Wiki, strongly Oppose. A short stroll through the global filters reveals a situation of use that, to say the least, doesn't correspond to the local balances concerning limitations on editors and protection of articles. —מקף⁻ණ (Hyphen) 20:10, 16 March 2023 (UTC)
- Could you give some examples of what you're referring to? — TheresNoTime (talk • they/them) 21:09, 16 March 2023 (UTC)
- Support--BRP ever 22:14, 16 March 2023 (UTC)
- Strong support. Sgd. —Hasley 15:23, 17 March 2023 (UTC)
- Support * Pppery * it has begun 14:00, 18 March 2023 (UTC)
- Oppose. I think that they should be opt-out on global sysop wikis, but I do not think that we should be making decisions to enable the blocking of users on local wikis based merely off of the decision of some local meta admin to enable blocking on a filter. There are several global filters that currently block a user (or block autopromotion), and there are very good reasons why making this sort of thing opt-in for larger wikis rather than opt-out is a good idea from a risk mitigation perspective. — Red-tailed hawk (nest) 21:48, 18 March 2023 (UTC)
- not sure if that's perhaps a mistake which should be corrected? There are three active global filters with either Revoke the user's autoconfirmed status or Block the user and/or IP address from editing enabled  even though it clearly says „do not set on global filters“ at the filter editor. Johannnes89 (talk) 23:15, 18 March 2023 (UTC)
- This is why I said
$wgAbuseFilterLocallyDisabledGlobalActions should be set true for the actions that are disabled by default (block, degroup, rangeblock). Anyway, the consensus indicated that there should be no blocks (Requests for comment/Global AbuseFilter#What actions should be allowed?), so it's probably a mistake.--SRuizR 01:29, 19 March 2023 (UTC)
- T332521 filed for setting
wgAbuseFilterLocallyDisabledGlobalActions — TheresNoTime (talk • they/them) 20:14, 19 March 2023 (UTC)
- Thank you for writing this patch, TNT. — Red-tailed hawk (nest) 14:17, 20 March 2023 (UTC)
- How long have they been like that, and what is the sort of accountability process like for doing this against community consensus? My big problem with this is that local wikis don't have a real way of holding Meta sysops to account for creating global filters that break something on their wiki, and the harm outweighs the benefits in well-governed large wikis. Let them opt-in if they want, but I see no need to force them into accepting this if they don't affirmatively want to make a change. — Red-tailed hawk (nest) 01:49, 19 March 2023 (UTC)
- It is quite concerning that these filters were set against policy for what seems to be a fairly long time without anyone noticing or fixing it. Galobtter (talk) 01:33, 20 March 2023 (UTC)
- It's a little irritating given the "do not set on global filters" text, but I guess mistakes happen — this change should prevent this in the future — TheresNoTime (talk • they/them) 01:51, 20 March 2023 (UTC)
- Filters 144, 163 and 306 have now had any actions marked "do not set on global filters" removed — TheresNoTime (talk • they/them) 19:51, 19 March 2023 (UTC)
- Support --*Fehufangą ♮ ✉ Talk page ♮ 23:00, 18 March 2023 (UTC)
- Oppose Big wikis should be able to decide this for themselves. They generally have enough abuse filter editors to handle local abuse themselves. They should have the ability to import the global filters they want, but this should be the decision of each of these wikis individualy. Animal lover 666 (talk) 12:50, 19 March 2023 (UTC)
- Support Luix710 (talk) 10:48, 20 March 2023 (UTC)
- Support given how arbitrary the current classification is. Taavi (talk!) 14:30, 20 March 2023 (UTC)
- Oppose I agree with Red-tailed hawk that opt-in is better for wikis like Commons than opt-out. Abzeronow (talk) 19:12, 20 March 2023 (UTC)
- @Abzeronow @Animal lover 666 Hi, I'd like to note that nothing in the proposal prevents that from happening. As you can see, enwiki already said they wish to opt out from global filters, and if Commons wishes to do so as well, it can make that decision as well. Martin Urbanec (talk) 16:18, 21 March 2023 (UTC)
- That's true, and I would likely vote on Commons to opt out. Thanks for your reply though. I definitely understand your proposal has very noble intentions. Abzeronow (talk) 16:24, 21 March 2023 (UTC)
- For what it's worth, Commons is currently discussing the issue now. — Red-tailed hawk (nest) 02:19, 22 March 2023 (UTC)
- Support. -- Jeff G. ツ (please ping or talk to me) 01:31, 21 March 2023 (UTC)
- Support Sensible with local opt-out possible. One issue is that not all meta sysops are global EFM/EFH etc, so it might be hard to see any replication etc. Also, some local community might want meta access to filters, so there might be a glut of RfLA which may be a little troublesome, I would suggest that if this passes we have local EFM/EFH and the applications can be significantly shorter. For read access I would think a simple grant on RFH should be fine as sysops here can judge the person reliablity, for the latter a shorter say 3 days request on RFH for any large wiki sysop which is willing to help should be adequate. Since the access is tied to helping a particular wiki, I think being sysop should be alright as community trust and Meta:Snowball can be adequately addressed. Camouflaged Mirage (talk) 11:19, 23 March 2023 (UTC)
- Making a local EFH should be easy, could just let local crats manage it at RFH with an easy guideline (perhaps for any non-temporary admin on a production project). — xaosflux Talk 14:18, 23 March 2023 (UTC)
- @Xaosflux Created Meta:Requests for comment/Create local meta abuse filter helper and abuse filter manager role just in case the creation on phab requires RFC consensus. Thanks. Camouflaged Mirage (talk) 10:09, 24 March 2023 (UTC)
- Support sensible. Big wikis are the exception, not the rule. Opt-out provisions are more than sufficient. HouseBlaster (talk) 03:23, 26 March 2023 (UTC)
- Support No concerns as of right now. NgocAnMaster (talk) 15:58, 26 March 2023 (UTC)
- Support Nosferattus (talk) 19:50, 30 March 2023 (UTC)
- Support --Novak Watchmen (talk) 15:53, 3 April 2023 (UTC)
- Strong support Why should any Wikimedia project be denied of global abuse filters? Opt-out or opt-in, just give the option. –Vipz (talk) 16:00, 3 April 2023 (UTC)
- Oppose. As somebody who has been maintaining some of the global filters for at least a year and a half I can say that a lot of them are currently written in a way relying on the fact that they are only enabled on smaller wikis. The stream of false positives – often anonymous users or newbies who do not know where to report filter errors, let alone ones in global filters – is manageable but it requires somebody to actually look at the filter hits, which I can say is not nearly being done 24/7. No need to rush and drastically increase the rate of false positives from a load of newly added wikis; one can ask communities one-by-one to opt in, ideally over a larger timespan. If it ain't broke, don't fix it. Also per JAn Dudík. ~~~~
User:1234qwer1234qwer4 (talk) 19:41, 3 April 2023 (UTC)
- Support. --Dr-Taher (talk) 19:49, 6 April 2023 (UTC)
- Oppose I get it – most abuse filters are specifically written for small wikis with few to no admins with experience in creating/maintaining abuse filters. But global abuse filters are global for a reason – I don't know how many are written for larger wikis, but I don't see how this will curb LTA activity. Also per 1234qwer1234qwer4 and Jan Dudík. --SHB2000 (talk | contribs) 09:06, 10 April 2023 (UTC)
- @SHB2000: There are at least a couple of projects listed as "large" but they are 'large' only in number of articles. An example is the project I'm an admin on, sh: (Serbo-Croatian Wikipedia). The amount of LTA cross-wiki spam our project is experiencing is overwhelming, to say the least, and there are only two active admins to actively clean it all up. Feel free to take a look in our block and deletion logs. –Vipz (talk) 20:42, 10 April 2023 (UTC)
- Neutral I'd love to see if there are other opt-out chances from other large sites, not an "enwiki can't but others can" case. --Liuxinyu970226 (talk) 00:17, 1 May 2023 (UTC)
- @Liuxinyu970226 - looks like jawiki just joined the opt-out list above. — xaosflux Talk 15:20, 3 May 2023 (UTC)
- @Xaosflux Not only this, it's also unclear that whether the title, and the context of this RFC has grammar errors, title says opt-out, for me, means to disable g.filters, but the enwiki and jawiki decisions look like just early-bird doing so, should the RFC be more modified to avoid glitches as it looks rather like the proposer wanna opt-in (aka enable) the g.fliters. Liuxinyu970226 (talk) 06:07, 10 May 2023 (UTC)
- @Martin Urbanec: ^^ Liuxinyu970226 (talk) 06:08, 10 May 2023 (UTC)
- Currently global abuse filters are enabled on small & medium wikis and per opt-in for large wikis if those communities wish to be covered by global filters (e.g. frwiki & Wikidata decided to opt-in). This RfC proposes an opt-out approach -> enable global filters on all wikis who do not explicitly opt-out (like enwiki & jawiki did now). Johannnes89 (talk) 07:23, 10 May 2023 (UTC)