Legoktm added a comment.
+1 to using replag based solutions instead of artificial rate limits. I suspect that most bots do not have proper rate limit handling because the expectation is that they don't run into them. I would suggest implementing something like rMWde9f9bda7db9: API: Optionally inclu
Multichill added a comment.
In T184948#4145885, @Sjoerddebruin wrote:
Seems like this is affecting the MassMessage extension: https://www.wikidata.org/w/index.php?title=Special:Log/massmessage&offset=&limit=250&type=massmessage&user=
T192690TASK DETAILhttps://phabricator.wikimedia.org/T184948EMA
hoo removed a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T184948EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, hooCc: Stashbot, Edgars2007, Daniel_Mietchen, Pasleim, Magnus, abian, Lucas_Werkmeister_WMDE, ArtixKreiger,
Lucas_Werkmeister_WMDE added a project: Wikidata-Ministry-Of-Magic.Lucas_Werkmeister_WMDE updated the task description. (Show Details)Lucas_Werkmeister_WMDE set the point value for this task to "2".
CHANGES TO TASK DESCRIPTION...* dispatch lag (often not taken into account yet)
=Next steps==TODO=
hoo added a comment.
If we make sysop and bot subject to rate limits, the "user"-limits from the following apply (unless we set a higher limit for them specifically):
P6982 Wikidata: Effective $wgRateLimits
Potential problems I could see:
move 8 per minute (although not relevant to entity namesp
Addshore added a comment.
In T184948#4078853, @Multichill wrote:
That's what you getting from being a bit more liberal for a long time. Tool rights have to be approved, bot rights have to be approved, all can be revoked when needed. If this really is a problem, take action or clearly identify the
