Needs community discussion?

In T87431#993047, @Glaisher wrote:

Needs community discussion?

No need to bureaucratise such minor but very helpful changes. (common sense)

Change 186743 had a related patch set uploaded (by Glaisher):
Set $wmgAbuseFilterEmergencyDisableCount to 25 at commonswiki

https://gerrit.wikimedia.org/r/186743

Patch-For-Review

In AF 137, it says

It reached the limit of matching more than 5.00% of actions.

So I guess [[ https://www.mediawiki.org/wiki/Extension:AbuseFilter#Configuration | $wgAbuseFilterEmergencyDisableThreshold ]] should be changed as well?

Change 186743 merged by jenkins-bot:
Set $wmgAbuseFilterEmergencyDisableCount to 25 at commonswiki

https://gerrit.wikimedia.org/r/186743

@Rillke: maybe you are right, the problem still exists after disabling/reenabeling the filter:

Warning: This filter was automatically disabled as a safety measure. It reached the limit of matching more than 5.00% of actions.

So $wgAbuseFilterEmergencyDisableThreshold needs a change as well.

~sigh~

$wmgAbuseFilterEmergencyDisableThreshold does indeed to be changed, but the questions is, to what value. Would 10% (0.10) be enough for the time being?

In T87431#1057342, @tomasz wrote:

$wmgAbuseFilterEmergencyDisableThreshold does indeed to be changed, but the questions is, to what value. Would 10% (0.10) be enough for the time being?

Or to 30 (to be on the save side)?

To get this done, can we agree on a value here?

In T87431#1109231, @Glaisher wrote:

To get this done, can we agree on a value here?

I think 30% (= 0.30) should be enough.

Change 195938 had a related patch set uploaded (by Glaisher):
Set $wmgAbuseFilterEmergencyDisableThreshold to 0.30 at commons

https://gerrit.wikimedia.org/r/195938

There are some concerns that 30% may have an impact on performance. IMO, we can see how 10% works for now.

In T87431#1145293, @Glaisher wrote:

There are some concerns that 30% may have an impact on performance. IMO, we can see how 10% works for now.

Why, can you elaborate pls? :-)

If it is not possible use 10, better than nothing.

@Aklapper: Please elaborate why you removed SRE. Maybe someone there can say something about the potential permanence issues. :-)

@aaron, @ori: Any of you have an idea if setting $wmgAbuseFilterEmergencyDisableThreshold to 0.30 for Commons could have an impact on performance? Or if you don't have, who could judge / answer this instead?

@Steinsplitter: Sorry for not explaining - I simply don't see how Operations is related to this specific question. :)
Would be great if @Glaisher could answer T87431#1145413.

In T87431#1148452, @Aklapper wrote:

@Rillke: If you are after attacking people: It's not acceptable.

Not my intention, hence removed comment in question. Still possible some groups are overworked or understaffed.

(agree that this is not related to operations)

I was going to SWAT this and two deployers mentioned to me about an impact on performance by this. I myself, don't have an idea about what it could do in regards to performance.

In T87431#1149228, @Glaisher wrote:

two deployers mentioned to me about an impact on performance by this. I myself, don't have an idea about what it could do in regards to performance.

So did you ask why they think setting the variable to 30% would have a negative impact on performance? Also why don't these 2 devs choose not to comment here? Don't they have a Phabricator account?

In the case of messing up a filter, a lot of edits get discarded before the filter is deactivated but this shouldn't impact site performance, should it?

In T87431#1149228, @Glaisher wrote:

(agree that this is not related to operations)

I was going to SWAT this and two deployers mentioned to me about an impact on performance by this. I myself, don't have an idea about what it could do in regards to performance.

ok, but wondering why payed staff isn't able to -1 a patch self (and adding a short comment why)... :-)

@Steinsplitter: I didn't "block" the patch, I just asked Glaisher whether someone (thinking @ori or @aaron) had been asked whether this would have a performance impact.

If there's an "emergency disable" threshold it probably exists for a reason, and performance is one likely reason. Or maybe the threshold exists just to avoid excessive disruption by a filter that accidentally matches too many edits; since I don't know, I asked a question but didn't -1.

If there's an "emergency disable" threshold it probably exists for a reason, and performance is one likely reason. Or maybe the threshold exists just to avoid excessive disruption by a filter that accidentally matches too many edits; since I don't know, I asked a question but didn't -1.

I added the threshold. The purpose is indeed to avoid excessive disruption (i.e., a filter that matches 30% of all edits is probably a broken filter). I don't believe there would be a performance impact.

In T87431#1152871, @werdna wrote:

I added the threshold. The purpose is indeed to avoid excessive disruption (i.e., a filter that matches 30% of all edits is probably a broken filter). I don't believe there would be a performance impact.

As long as that's the case I don't have any objections to this going out in swat anymore (which is all I asked for yesterday--clarification first :))

As long as that's the case I don't have any objections to this going out in swat anymore (which is all I asked for yesterday--clarification first :))

Bear in mind I don't maintain AbuseFilter anymore so it might be worth asking @aaron, @ori, @csteipp or similar for confirmation. I can't imagine that blocking lots of edits would be a performance problem – more likely the opposite – but I can't take responsibility for confirming that.

Hoo man		Mar 26 4:58 PM

Patch Set 1: Code-Review+1

Approving from an AbuseFilter perspective (no idea what the community things, this can be disruptive on their side): This should not cause technical issues beyond the obvious one.

^^

Change 195938 merged by jenkins-bot:
Set $wmgAbuseFilterEmergencyDisableThreshold to 0.30 at commons

https://gerrit.wikimedia.org/r/195938