See parent task

See parent task

See parent task

@Pintoch Please recheck the number of edits. The time in the Grafana graph is in your timezone, not in UTC. Some bots does not edit at all in this period.

Note PetScan query maxlag first and sleep for some seconds if the maxlag is high. The edits are nevertheless done regardless the maxlag. This was meaningful before dispatch and query service lag is added to maxlag (see T221774#5692489), but it should now be reconsidered.

Many bots already respect maxlag=5, though as maxlag (from WDQS) is updated per minute, they may run intermittently.

Consider remove autoblock from User:Doqume

User:Doqume is blocked, the autoblock still exists.

In T240316#5728232, @Lea_Lacroix_WMDE wrote:

@Bugreporter That seems unlikely. QuickStatementsBot is blocked since October 28th, and daily users of the tool only started reporting this issue yesterday.

I don't know any way to get the number of tried resolutions (or views) of a non-existent domain.

Yes.

I don't think we will have many images with titles (or file names) including a namespace or interwiki prefix.

Actually the reason is QuickStatements use a single IP to edit on behalf of different users, so once a QuickStatement user is blocked other is autoblocked.

In Commons it is called prominence.

Note we don't need MediaWiki backend in a new system.

I don't think how this is useful; there's legitimate (though rare) reason to edit others' JS/CSS page from time to time, e.g. to replace the usage of deprecated JS module.

Strong oppose for reason stated in T142068: Possible to circumvent shortening URL list by Special:Search (someone please make this task public); In particular development of Labs tools are not subject to security review of any kind.
I suggest T232240: New service to shorten wmflabs URLs instead.

This is more useful while searching Structured Data in Commons.

Boldly reopen, ideally no Qid should be "lost" - and no database transaction should be made for failed entity creation.

No longer relevant after T236901: Use elastic for SpecialEntitiesWithoutPage (EntitiesWithoutTermFinder)

No longer relevant after T236901: Use elastic for SpecialEntitiesWithoutPage (EntitiesWithoutTermFinder)

No longer relevant after T236901: Use elastic for SpecialEntitiesWithoutPage (EntitiesWithoutTermFinder)

You may want to complete T232446: Compress new Wikibase tables on new master before failover.

This results in security issue (T239466: Possible to circumvent title-blacklist).

This stops working. See T238105#5686574

In my opinion an abusefilter-bypass is useful though should normally be granted to no one permanently; my rationale is to prevent https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=WMFOffice&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter= from being happen.

In T238825#5691807, @Dzahn wrote:

Really wildcard or more like "populate DNS (langlist.tmpl) with all language codes from ISO-693-3 table"?

This does not timeout but the number of results is also wrong:
https://www.wikidata.org/w/index.php?sort=relevance&search=haswbstatement%3AP31%3DQ6256+intitle%3A%2F%5Ba-z%5D*%2F&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns0=1&ns120=1&ns146=1

Note Wikidata explicitly overrided the behavior in T184025: Default deletion log for Wikidata items doesn't include label. The behavior in Wikidata should be preserved,

This column is deprecated; See T188327: Deploy refactored actor storage.

Actually maxlag may be more than 5 second for up to one hour. tools should not break (not "give up") even no edits can be made.

In T238803#5680279, @Koavf wrote:

I object to deletion: as long as we still own the domain names (that is, "we" being the WMF, not us personally), URIs should stay active and point to something meaningful. The only thing we ever should have outright deleted was the Siberian Wikipedia.

Currently multiple tools are broken because the time that make maxlag back to normal is much longer than the total time the tool retries edits (see this and this).

Stalled for further discussion (consensus needed).

Note very old browsers may not support HSTS preload list or even HSTS itself; probably we want to configure a specific 403 message (or still redirect them when user agent is these browsers).

This does not seem to be any bug in Wikimedia code (https://codesearch.wmflabs.org/search/?q=mekecat&i=nope&files=&repos=). You may adjust your custom script or provide a clear step to reproduce it.

See https://www.mediawiki.org/wiki/Extension:WikibaseCirrusSearch

Related messages:
https://commons.wikimedia.org/wiki/MediaWiki:Wikibase-mediainfo-summary-wbsetlabel-add/de
https://commons.wikimedia.org/wiki/MediaWiki:Wikibase-mediainfo-summary-wbsetlabel-remove/de
https://commons.wikimedia.org/wiki/MediaWiki:Wikibasemediainfo-diffview-label/de
https://commons.wikimedia.org/wiki/MediaWiki:Wikibasemediainfo-entitytermsforlanguagelistview-caption/de

If a tool is created it should directly query the database (replica have near-infinite time limit) instead of calling API.

not all (special) projects are Wikidata clients.

See https://meta.wikimedia.org/wiki/Talk:Wikimedia_URL_Shortener#TranslateWiki

If this should happen in MediaWiki, it will be considered as a bug. The text is over-escaped.

The purpose of this task is also move the wiki to another cluster.