The first step, enabling the configuration on test, test2, and mw.org has been completed: https://gerrit.wikimedia.org/r/#/c/48070/

If no issues are identified, we'll enable to permission in the next few days, and and continue to monitor performance while Stewards write rules for these enabled wikis.

Pending the merging of https://gerrit.wikimedia.org/r/#/c/42800/, stewards probably aren't going to do anything with it, except perhaps very limited testing.

(In reply to comment #2)

Pending the merging of https://gerrit.wikimedia.org/r/#/c/42800/, stewards
probably aren't going to do anything with it, except perhaps very limited
testing.

I came to think that this is the wrong approach and would rather see this fixed within the AbuseFilter extension itself, possibly even allowing local admins to disable global filters.

(In reply to comment #1)

If no issues are identified, we'll enable to permission in the next few days,
and and continue to monitor performance while Stewards write rules for these
enabled wikis.

I'm a bit confused as to the status of this bug.

I think Jasper is saying bug 43761 should be a blocker for this? If that's the intent, please add it as a blocker.

Hoo, let's keep the discussion about local disabling there.

Global AbuseFilter is now active on all small and middle-sized Wikimedia wikis (with some exceptions).

Well...

'default' => false,
'small' => true,
'medium' => true,
'private' => false,
'fishbowl' => false,
'nonglobal' => false,

// Effectively repeat nonglobal entry above because both labswiki and labtestwiki are also medium
'labswiki' => false,
'labtestwiki' => false,

'enwikisource' => true, // T78496
'frwiki' => true, // T120568
'metawiki' => true,
'testwiki' => true,
'test2wiki' => true,
'mediawikiwiki' => true,
'specieswiki' => true,
'incubatorwiki' => true,
'wikidatawiki' => true,

Is the non-deployment to global wikis a community (i.e needs permission) or a tech (e.g large wikis creating performance problems) issue?

Both probably

The tech component (aiui), is that the global filters will count against the AF runtime limits. So the global filters will reduce the number of local-wiki specific rules that can run. We could raise the limits and accept that some edits are going to take longer to save.

I think the community issue is bigger-- are the large-wiki admins comfortable with the global filter editors having that type of control over the wikis. I'm not sure who the stakeholders are on each of the large wikis to make that determination, or what the correct process would be to decide that.

I can initiate a survey at dewiki, if wished, but I can't tell you the process for other wikis.

On enwiki, one can ask for feedback in the https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard

On eswiki, it could be brought up on https://es.wikipedia.org/wiki/Wikipedia:Filtro_de_ediciones/Portal/Archivo/Implementaci%C3%B3n/Actual or https://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Archivo/T%C3%A9cnica/Actual

But I think the limits should be split first, with global filters counting against its own limits. It's not appropriate that a steward tweaking one global filter inadvertently disables Very Important Filter™ on xywiki (or that a local filter makes the steward filter unable to run).

I agree that there should be separate global and local filter limits. With no impact on local projects, this shouldn't need any sort of community approval, other than customary input (perhaps through an RfC?) that allows people to point out concerns and perhaps develop systems through which other individuals can become involved in the process.

At some point, someone decided that it made sense to centralize some abuse responses, and made things like global locks, global spam blacklists, global title blacklists, etc. Not sure when we decided to move from that to endless bureaucracy and pretending that each project exists separately of all the others.

In T46975#2166866, @Ajraddatz wrote:

(...) With no impact on local projects, this shouldn't need any sort of community approval (...)

That's the problem, at the moment it is not possible to deactive a global filter locally, so it will have an impact.

Hi! @apaskulin , In your opinion, does this task fit into the scope of removing non-inclusive language? Thanks!

@JArguello-WMF, as far as I can tell, this task doesn't fit directly into the scope of removing non-inclusive language.