Page MenuHomePhabricator

Document architectural decisions for WikidataQuality extensions
Closed, ResolvedPublic


In it's current form (for as far as I've gotten in my review), the WikidataQuality extensions implement functionality that could be run entirely off toollabs. If there isn't a strong, long-term goal achieved by having the tools live on the cluster, then running them there needlessly increases our attack surface. It also means that updates to the constraint / validation data must be performed by a deployer, and significant changes in the future will need another security review.

@aude / @Lydia_Pintscher, can one of you explain where this fits into Wikidata's long-term architecture, and why these tools need to be run on the cluster instead of a interacting with the wikis over the api?

Event Timeline

csteipp raised the priority of this task from to Needs Triage.
csteipp updated the task description. (Show Details)
csteipp added subscribers: Andreasburmeister, csteipp, Tamslo and 5 others.

Both the constraints validation and checks against 3rd party databases are supposed to be a pretty integral part of Wikidata. It's part of the long-term strategy to enable the editor community keep the data in good shape.
In practice this means it should be tightly integrated in the UI of an item for example to show issues with a particular statement for example. This could all be achieved with gadgets and so on but it is not good long-term. This is basically productizing existing on-wiki hacks.

Does that answer your question?

Lydia_Pintscher claimed this task.

Please reopen if your questions have not been addressed fully.
Thanks for the quick reviews!