| agray added a comment. |
To follow up on @Jheald and @Lydia_Pintscher's comments here - for a lot of use-cases, I agree that a lag measured in a few hours isn't much of a problem, because the underlying data is fairly static. Most property values don't change minute-to-minute or even month-to-month, most ontologies and hierarchies are reasonably stable, and so on. Queries which are "tell me something interesting about the underlying data" will tend to return reasonably good results whatever the update lag, assuming that it's not something that changes frequently or has been recently worked on.
But maintenance work often presumes a much quicker response rate, and people have built workflows around that expectation - it has been, historically, pretty reliable at maintaining an update lag of a minute or so. Maybe we've just got soft and lazy because it's been so good :-)
To give a practical example, I have a regular data-cleaning workflow which uses a series of related queries to look at a class of people, with one set of queries identifying if the group is complete, another set bringing up various bits of metadata so it can be manually checked, and a third set looking for inconsistencies between them. Corrections at one stage can feed into another, and cleaning a set of data often means running the reports two or three times to check everything fits together accurately after changes have been made. Once I'm confident it's all complete and comprehensive, I mark it as validated and move on to the next one.
In this sort of situation, a few minutes lag is no real problem, but a few hours lag makes it very challenging to complete a single batch of data cleaning in one session. If that then means having to do it over several days, it leads to extra work as well as an increased chance of mistakes through human error (eg losing track of which bits I've done).
I don't want to say this is the biggest problem there is, or anything like that, and I would completely agree that ultimately accuracy of the results and the system being reliably up are very much priorities #1 and #2, with lag behind them at #3. However, increasing lag does still have noticeable impacts on maintenance work, and doing that work becomes more difficult once lag gets sufficiently long.
Cc: agray, Jheald, Magnus, Pintoch, gerritbot, Mathew.onipe, Stashbot, Lydia_Pintscher, EBjune, debt, Joe, Smalyshev, Gehel, Aklapper, Legado_Shulgin, Nandana, thifranc, AndyTan, Davinaclare77, Qtn1293, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Th3d3v1ls, Hfbn0, QZanden, merbst, LawExplorer, Zppix, Jonas, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
